Security plugins often act as a high-level bandage for architectural vulnerabilities. While convenient, they execute late in the application lifecycle, consuming PHP workers and memory for tasks that are more efficiently handled by the web server. Hardening at the Nginx or Apache level ensures that malicious requests are intercepted and dropped before they ever touch the WordPress core, significantly reducing the attack surface and server overhead.
Core Section 1: Protecting wp-config.php
The wp-config.php file is the primary target in any WordPress-directed attack. It contains plaintext database credentials, unique authentication keys (salts), and core configuration constants. Allowing direct web access to this file, even if the server is configured to execute PHP, introduces unnecessary risk should a server misconfiguration occur.
Nginx Configuration
In your server block, add a specific location match to deny access. Using deny all ensures the server returns a 403 Forbidden status immediately.
Nginx
# Deny access to wp-config.php
location = /wp-config.php {
deny all;
access_log off;
log_not_found off;
}
Apache (.htaccess) Configuration
Place this snippet at the top of your .htaccess file, outside of the # BEGIN WordPress block to prevent it from being overwritten by core updates.
Apache
# Protect wp-config.php
<Files wp-config.php>
<IfModule mod_authz_core.c>
Require all denied
</IfModule>
<IfModule !mod_authz_core.c>
Order deny,allow
Deny from all
</IfModule>
</Files>
Core Section 2: Disabling xmlrpc.php
The xmlrpc.php endpoint was historically used for remote publishing and trackbacks. Today, it is primarily a vector for DDoS amplification and Brute Force attacks. Because a single XML-RPC request can execute hundreds of password attempts via the system.multicall method, it bypasses standard login rate limiters.
Nginx Configuration
Matching the exact URI and returning a 403 Forbidden is the cleanest way to neutralize this endpoint at the edge.
Nginx
# Disable XML-RPC to prevent DDoS and Brute Force
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}
Apache (.htaccess) Configuration
Using the Files directive prevents the script from being accessed by external agents.
Apache
# Block WordPress xmlrpc.php requests
<Files xmlrpc.php>
<IfModule mod_authz_core.c>
Require all denied
</IfModule>
<IfModule !mod_authz_core.c>
Order deny,allow
Deny from all
</IfModule>
</Files>
Cybersecurity Best Practices
Implementing these server-level changes is a critical step in WordPress hardening, but operational safety is paramount.
- Syntax Verification: Always validate configuration files before reloading the service. For Nginx, execute
nginx -t. For Apache, use apachectl configtest.
- Version Control: Track changes to
.htaccess or Nginx configuration files in a repository (e.g., Git) to allow for immediate rollbacks if a rule disrupts legitimate traffic.
- Environment Parity: Test these rules in a staging environment that mirrors your production web server version to ensure no unexpected behavior with existing directives.
By shifting these security responsibilities to Nginx or Apache, you establish a more resilient defense-in-depth strategy that preserves system resources for actual users rather than malicious bots.