Understanding the WordPress Attack Surface

WordPress security involves more than installing a security plugin or choosing a strong password. A website consists of several connected components, including the WordPress core, administrator accounts, plugins, themes, databases, uploaded files and web server configuration. Each component can introduce a potential entry point if it is not properly protected.

Cybercriminals may exploit outdated software, stolen credentials, vulnerable upload forms or incorrectly configured servers. Their objectives can include stealing information, injecting spam, redirecting visitors, distributing malware, manipulating search results or taking control of a website.

WordPress security hardening reduces these risks by restricting unnecessary access, preventing unauthorised code execution and improving detection and recovery. This guide examines the components attackers commonly target and explains how beginners can implement additional protection using Apache's .htaccess configuration file.

1. Which Parts of WordPress Can Hackers Attack?

Understanding the attack surface helps you prioritise security improvements.

No single setting protects every component. Effective WordPress security combines application-level controls, server configuration, network protection and regular maintenance.

2. Protect Sensitive WordPress Configuration Files

The wp-config.php file contains important settings, including database connection information and authentication keys. If an attacker can read this file, they may obtain information that helps compromise the website.

For Apache HTTP Server 2.4, add the following rule to the root .htaccess file, outside the WordPress-managed rewrite section:

# Protect sensitive configuration files
<FilesMatch "^(wp-config\.php|\.htaccess|\.htpasswd|debug\.log)$">
    Require all denied
</FilesMatch>

This denies HTTP access to files matching those names. It does not replace filesystem permissions, and it assumes the file is being processed by Apache with the required access-control directives enabled.

Step-by-step implementation

1. Back up the existing .htaccess file.

2. Open your hosting control panel and select File Manager.

3. Navigate to the main WordPress directory.

4. Enable the display of hidden files if .htaccess is not visible.

5. Add the code outside # BEGIN WordPress and # END WordPress.

6. Save the file.

7. Test the homepage, login page and normal website navigation.

You can also check that a direct HTTP request for wp-config.php is denied. Do not publish or share its contents during testing.

A 403 Forbidden response is generally expected for a denied request, although some hosts may return another protective response.

Important: This rule is intended for Apache. Nginx does not read .htaccess; equivalent protection must be configured by the hosting provider or server administrator. Keep sensitive files outside publicly accessible directories where practical, and restrict their filesystem permissions.

3. Disable Directory Listing

Directory listing occurs when a web server displays the contents of a directory instead of serving a page or denying access.

If directory listing is enabled, visitors may be able to see filenames or folder structures that should not be publicly browsable. This does not automatically expose every file, but it can provide attackers with useful information.

To disable directory listing on Apache, add:

# Disable directory listing
Options -Indexes

How to apply it

1. Back up .htaccess.

2. Add the directive outside WordPress's managed rewrite section.

3. Save the file.

4. Test a directory that has no index file, using a harmless test directory if possible.

The expected result is that Apache no longer generates a directory listing.

If the server returns an internal server error, your hosting provider may not permit the Options directive in .htaccess. Remove the line and ask the provider to disable directory indexing at server level.

Remember that disabling directory listing does not prevent direct access to files whose URLs are known. Sensitive backups, database exports and private documents must not be stored in publicly accessible locations.

4. Prevent PHP Execution in the Uploads Directory

The wp-content/uploads directory commonly contains images, documents and other media files. A vulnerable upload form or compromised plugin may allow an attacker to place a malicious script there.

On Apache 2.4, create or edit wp-content/uploads/.htaccess with the following rule:

# Block direct access to PHP-related scripts
<FilesMatch "\.(php[0-9]?|phtml|phar)$">
    Require all denied
</FilesMatch>

Step-by-step guide

1. Open wp-content/uploads in File Manager.

2. Create a file named .htaccess if your host supports it.

3. Paste the rule into that file.

4. Save the changes.

5. Upload a normal image through WordPress and verify that it still displays.

6. Ask your hosting provider to verify that PHP execution is disabled for this directory if you need stronger assurance.

This rule blocks direct web access to files matching the specified extensions. It is not a complete upload-security solution: it does not validate uploaded content, remove malicious files or cover every possible executable extension.

For stronger protection, validate upload types, restrict allowed file extensions, keep plugins updated and use server-level rules that prevent script execution in writable directories.

Nginx requires a server-level configuration instead. Do not place Apache directives in an Nginx configuration or assume that a .htaccess file works on every hosting platform.

5. Restrict Access to WordPress Core Files

The wp-includes directory contains important WordPress application code. Most files in this directory are not intended to be executed directly through arbitrary public requests.

An additional Apache rule can block direct access to selected PHP files within this directory:

# Block direct access to top-level PHP files in wp-includes
<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteRule ^wp-includes/[^/]+\.php$ - [F,L]
</IfModule>

Place this rule in the root .htaccess file outside the WordPress-managed rewrite section.

This example targets top-level PHP files within wp-includes. It does not block every PHP file in every subdirectory, and it is not a replacement for keeping WordPress updated.

Test the website thoroughly after applying the rule. WordPress multisite installations, specialised plugins and certain integrations may require different handling. If the site stops working, remove the custom rule and investigate the cause before trying another configuration.

Do not indiscriminately block all PHP requests under wp-includes, wp-admin or wp-content: legitimate WordPress functions and plugin endpoints may depend on them.

6. Protect the Login Page and XML-RPC Endpoint

The WordPress login page, usually wp-login.php, is a frequent target for automated password guessing. XML-RPC, available through xmlrpc.php, may also be abused when enabled and exposed.

Start with the following measures:

• Enforce MFA for administrator accounts.

• Use unique passwords and remove unused accounts.

• Configure rate limiting through a trusted security plugin, WAF or hosting service.

• Monitor failed login attempts and unusual authentication activity.

• Disable XML-RPC only if your website does not need it.

If you are certain XML-RPC is unnecessary, an Apache rule can deny access to the endpoint:

<Files "xmlrpc.php">
    Require all denied
</Files>

Add this to the root .htaccess file only after checking your integrations.

Some mobile applications, publishing tools and other services may rely on XML-RPC. Blocking it without checking dependencies can break legitimate functionality.

Do not use a blanket IP restriction on wp-login.php unless you know that every legitimate administrator uses an approved network. For dynamic IP addresses and remote teams, MFA and managed rate limiting are often more practical.

7. Add Security Headers Where Supported

HTTP security headers can help browsers handle content more safely. On Apache with the appropriate mod_headers module and permission to use Header directives, a basic example is:

<IfModule mod_headers.c>
    Header always set X-Content-Type-Options "nosniff"
    Header always set Referrer-Policy "strict-origin-when-cross-origin"
    Header always set X-Frame-Options "SAMEORIGIN"
</IfModule>

These headers can reduce certain risks associated with content-type interpretation, referrer information and framing.

However, security headers do not eliminate vulnerabilities in WordPress itself. Some websites intentionally allow selected pages to be embedded by other domains, so framing restrictions must reflect actual requirements.

A Content Security Policy (CSP) can provide further protection against certain script-injection attacks, but an incorrect policy may break analytics, advertising, payment forms or other scripts. Develop and test a CSP carefully, preferably in report-only mode first.

Enable HTTPS across the website and verify that certificates and redirects work correctly. Add HTTP Strict Transport Security (HSTS) only after HTTPS is correctly configured for every affected hostname. Incorrect HSTS settings can make a website inaccessible to visitors until the browser's policy expires.

8. Understand What .htaccess Cannot Protect

The .htaccess file is useful, but it has important limitations.

It applies to Apache HTTP Server when the relevant directives are permitted. Nginx, some managed hosting platforms and certain reverse-proxy arrangements use different controls.

Furthermore, .htaccess cannot reliably prevent an attacker from exploiting vulnerable plugin code, using a compromised administrator account or issuing malicious database queries through an application vulnerability.

For comprehensive protection, combine server rules with:

1. WordPress core, plugin and theme updates.

2. Multi-factor authentication and least-privilege user roles.

3. Secure file ownership and permissions.

4. A reputable WAF and login rate limiting.

5. Database backups and protected off-site copies.

6. File integrity monitoring and log analysis.

7. A tested incident response procedure.

WordPress's official hardening guidance recommends a layered approach rather than relying on a single security setting. <Cite refs={["turn368801search0","turn368801search2"]}/>

9. Troubleshooting Common .htaccess Problems

Before changing multiple rules, make one change at a time. This makes it easier to identify which directive caused a problem.

Always maintain an independent backup of .htaccess and know how to restore it through File Manager or your hosting control panel.

Securing WordPress requires protecting every layer, from login accounts and plugins to the database and web server. Attackers may exploit outdated software, weak credentials, insecure uploads or exposed configuration files, so a layered defence is essential.

Apache .htaccess rules can help deny access to sensitive files, disable directory listing and block direct execution of selected scripts in the uploads directory. However, they must be adapted to the hosting environment and tested carefully.

Start with backups, MFA, software updates and correct permissions. Then introduce server-level controls that match your website's needs. Monitor logs, investigate unexpected changes and maintain a tested recovery plan.

The objective is not to make attacks impossible, but to reduce exposure, limit damage and recover quickly if an incident occurs.

Phase 3 Advanced WordPress Security Database Protection Server Hardening and Intrusion Prevention

Phase 4 Enterprise-Grade WordPress Security Zero Trust Server Isolation and Advanced Threat Defence

Phase 5 Enterprise WordPress Security Multisite Hardening Network Isolation and Disaster Recovery