WordPress hardening for businesses: reducing the attack surface beyond plugins
By Kike Gandia · Co-Founder & CEO, OSCP
WordPress hardening is the set of configuration measures that reduce the attack surface of an installation before an attacker finds it. It does not replace a penetration test —which analyses vulnerabilities already present— but it is the baseline that determines how much damage an attacker can do if they gain an initial foothold.
Hardening the admin panel
The /wp-admin is the most heavily attacked target. Hardening measures include: moving or IP-restricting access to wp-login.php and /wp-admin/, implementing multi-factor authentication (MFA) for all users with administrative access, disabling public user registration where it isn't needed, and rate-limiting login attempts to mitigate brute force and credential stuffing.
Hardening files and permissions
Incorrect file permissions are one of the most common mistakes in agency-managed WordPress installations. The reference values are: wp-config.php at 400 or 440 (never 644 or 777), the /wp-content/ directory at 755, .php files at 644, and upload directories (/wp-content/uploads/) with PHP execution disabled. Direct access to wp-config.php from the outside must be blocked at the server level.
Hardening the API and exposed endpoints
XML-RPC should be disabled if it isn't used —and in most corporate installations it isn't. By default, the WordPress REST API exposes user and content information; any endpoints you don't need should be disabled or protected with authentication. The readme.html file, which reveals the exact WordPress version, should be removed.
Hardening the server and HTTP headers
HTTP security headers (Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Strict-Transport-Security, Referrer-Policy) are configured at the server or CDN level, not with plugins. A security plugin that manages them is better than nothing, but it adds an extra layer of dependency. PHP configuration is also part of hardening: disable allow_url_fopen and allow_url_include, and stop exposing the version in headers.
The limits of hardening without a security audit
Hardening reduces the visible attack surface but does not detect vulnerabilities already present in the code, broken application logic, plugins containing malicious code, or correct configurations that mask authentication flaws. It is the first step, not the only one. After hardening, a penetration test validates that the configuration is effective and detects what hardening alone cannot prevent.
FAQ
Can our web agency do the hardening, or do we need a cybersecurity company?
An experienced web agency can apply the basic hardening measures. What it cannot do is validate that they are effective under a real attack, or detect vulnerabilities in plugin code. That requires an external penetration test with an offensive methodology.
Does hardening affect the site's performance or functionality?
Well-applied hardening measures do not affect performance. Some restrictions (disabling XML-RPC, limiting REST endpoints) may require adjustments to existing integrations, so they are reviewed before being applied.
Related service
CMS penetration testing and audit service