How to Harden WordPress Without Breaking Your Site

Disable Dashboard File Editing

WordPress administrators can normally edit theme and plugin PHP files from the dashboard. If an administrator account or session is compromised, that editor gives an attacker a convenient way to modify executable code.

On a production site, code changes are better handled through SFTP, SSH, Git, your hosting tools, or a staging and deployment workflow.

Add this to wp-config.php:

define( 'DISALLOW_FILE_EDIT', true );

This removes the Theme File Editor and Plugin File Editor. Normal theme and plugin updates continue to work.

Verify it

Log in as an administrator and confirm the file editor options no longer appear under Appearance or Plugins.

Block PHP Execution in Uploads

wp-content/uploads/ is meant for uploaded media and files. A standard WordPress installation does not need to execute PHP from this directory.

This matters because an upload vulnerability is much more dangerous if an attacker can place a PHP web shell in a writable directory and execute it directly.

Apache or LiteSpeed

Where directory-level .htaccess rules are supported, place a rule in wp-content/uploads/.htaccess that denies PHP-like files:

<FilesMatch "\.(php|php[0-9]|phtml|phar)$">
    Require all denied
</FilesMatch>

Nginx

For Nginx, the protection belongs in the server configuration:

location ~* /(?:uploads|files)/.*\.php$ {
    deny all;
}

WordPress includes this type of restriction in its Nginx configuration guidance.

Verify it

On a staging site or during a controlled test, place a harmless PHP file in uploads and request it directly. The server should deny the request rather than execute the file. Remove the test file afterward.

Protect Sensitive Files and Directory Access

Configuration files, debug logs, backups, dotfiles, and development artifacts should not be downloadable through the browser.

Protect sensitive files

On Apache 2.4+, a rule can deny browser access to specific files:

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

Adapt the list to your environment. Database exports, backup archives, old configuration copies, .env files, version-control metadata, and temporary development files should not be left publicly accessible.

See the official WordPress Apache configuration guidance.

Disable directory listing

If Apache is configured to show directory indexes, disable them unless you intentionally operate a browsable file directory:

Options -Indexes

Verify it

• Request protected files directly and confirm their contents are not exposed.
• Check any backup or debug-log location you intentionally protected.
• Request a directory without an index file and confirm it does not display a file listing.

Disable or Restrict WordPress Features Only When You Do Not Need Them

XML-RPC, the REST API, and Application Passwords are legitimate WordPress features. Hardening does not mean disabling them automatically. Reduce access only where the site does not need it, and test the functionality that depends on each feature.

add_filter( 'wp_is_application_passwords_available', '__return_false' );

Verify these changes

Test the site logged out as well as logged in. Submit public forms, place a WooCommerce test order, use live search, check frontend account features, and test any external application connected to WordPress.

If a legitimate integration stops working, identify the exact feature or endpoint it requires rather than rolling back every hardening control.

Reduce Easy Reconnaissance, But Do Not Rely on Obscurity

Hiding WordPress version strings, reducing username enumeration, cleaning unnecessary head metadata, and changing the login URL can reduce easy reconnaissance and generic bot noise.

They are secondary controls. They do not patch vulnerable software, protect a stolen administrator password, stop executable malware, or replace firewall and login protection.

• Hide WordPress version: removes an easy fingerprint, but updates matter far more.
• Block user enumeration: makes trivial username discovery harder; check public author and API functionality afterward.
• Clean WordPress head: removes unnecessary metadata; check feeds or discovery features you use.
• Custom login URL: can reduce generic requests to wp-login.php, but does not replace 2FA or rate limiting.

Add Security Headers Carefully

Security headers tell browsers how your site may be loaded, embedded, and interpreted. Some are reasonable low-risk defaults. Others should be deployed only after testing the actual site.

CSP: report before enforcing

A Content Security Policy can reduce what unauthorized browser content is allowed to load, but a generic policy copied from another site can easily break legitimate scripts and integrations. Start in report-only mode, test important frontend flows, review violations, and enforce only after required resources are accounted for.

HSTS: use it only when HTTPS is permanent

HSTS tells browsers to use HTTPS for a defined period. Be especially careful with includeSubDomains and preload because they can affect hostnames beyond the WordPress installation and are not easy to reverse immediately.

Verify your headers

curl -I https://example.com/

After deploying CSP or other restrictive policies, test important pages in a browser and review the developer console for blocked resources or broken functionality.

Verify Your Hardening Changes

Do not finish with a list of enabled settings. Check that the protections are actually working and that legitimate functionality still works with them in place.

For WooCommerce, membership, LMS, booking, or heavily integrated sites, test the full user journey: login, registration, password reset, forms, search, checkout, payment confirmation, account pages, API clients, and third-party integrations.

The safest hardening configuration is the strictest one you have actually tested, not simply the strictest option available.