Security Hardening

Hardening only pays off when it is aimed at the attacks that happen. For WordPress sites they are, roughly in order of how often they lead to a compromise:

WordPress core itself is rarely the entry point: it has a dedicated security team, and fixes are released as minor versions that install automatically and are backported to older branches. The weak points are the extensions and the accounts, so most of this page is about limiting what an attacker can do once one of them fails.

Core is not immune, though, which is why core security releases are applied the day they ship. WordPress 7.1.4 (2026-10-28) is a security-only release whose most serious fix closes a weakness in the upgrade process that could lead to remote code execution during the upgrade window; it also fixes stored XSS in crafted block markup, the Interactivity API, Customizer selective refresh, privacy data removal requests, user logins and the Categories, Playlist, Image and comments-pagination blocks, a stored denial of service in the Interactivity API, unauthenticated discovery of unpublished Customizer changesets, Notes readable by users who cannot edit the post, and it updates the bundled root certificates. The announcement asks site owners to update immediately; sites with automatic background updates receive it on their own (see Updates and Auto-Updates).

Source: WordPress News: WordPress 7.1.4

No single setting stops every attack, so Lumen Press applies controls in layers, each of which still helps when an outer one is bypassed: the edge (a CDN or web application firewall), the web server, WordPress and its extensions, the accounts, and the data. Monitoring and a rehearsed incident response cover all of them.

Login cookies and application passwords are bearer credentials, so every WordPress site needs HTTPS.

The site address must use HTTPS in Settings > General (the home and siteurl options). Since 5.7, Tools > Site Health detects when HTTPS is available but unused and offers Update your site to use HTTPS, which switches both options and rewrites old http:// links in content on the fly. With WP-CLI, wp search-replace rewrites them permanently, as described in Importing, Exporting and Migrating.

FORCE_SSL_ADMIN forces the dashboard and logins over HTTPS; it must be defined in wp-config.php, not in a plugin. The older FORCE_SSL_LOGIN was deprecated in 4.0. When TLS ends at a load balancer or CDN and the request reaches PHP over HTTP, WordPress believes it is on HTTP and loops redirecting to HTTPS. The fix is to trust the proxy’s X-Forwarded-Proto header, and only from that proxy:

Source: Advanced Administration Handbook: HTTPS

The header-trust lines are only safe when PHP is reachable through the proxy alone. HSTS (Strict-Transport-Security) is sent by the web server, as shown in Security headers. TLS configuration itself (certificates, protocols, HTTP/2 and HTTP/3) is in Web Servers: Apache and nginx.

Since 6.8, WordPress hashes user passwords with bcrypt through PHP’s password_hash(), replacing the portable phpass hashes used since 2.5. Because bcrypt only reads the first 72 bytes, WordPress first computes an HMAC-SHA384 of the password (keyed with wp-sha384) and hashes that; the stored value is marked with a $wp prefix, so user_pass starts with $wp$2y$ followed by the cost. Old phpass hashes ($P$) still validate and are replaced the next time the user logs in, so a site upgraded from an older version holds a mix until everyone has logged in once. Application passwords, which are long random strings, are hashed with the faster BLAKE2b instead ($generic$), as described in Users, Roles and Profiles.

On the Lumen Press test site, under PHP 8.4, every hash started with $wp$2y$12$ (the query is shown in Users, Roles and Profiles). That cost is PHP’s default, which PHP 8.4 raised from 10 to 12, so the same WordPress version produces cheaper hashes on PHP 8.3. Two filters control the algorithm and its options, and wp_password_needs_rehash() (6.8) compares a stored hash against them, so a change is applied gradually at each user’s next login. Lumen Press pins the cost in a must-use plugin so it does not depend on the PHP version:

Source: Code Reference: wp_hash_password_options

Saved as wp-content/mu-plugins/lumen-password-hashing.php, it made wp_password_needs_rehash() return true for the existing cost-12 hashes, and after tom.author logged in his hash started with $wp$2y$13$ while the others kept cost 12. Each step of cost doubles the time of every login, so it should be measured on the production hardware. The wp_hash_password_algorithm filter can switch to Argon2id (PASSWORD_ARGON2ID, when PHP was built with it); on the test site the new hashes started with $argon2id$v=19$m=65536,t=4,p=1 and the old bcrypt ones still validated (and were flagged for rehashing).

Core does not enforce password strength: it shows a strength meter and asks to confirm a weak password. Resetting a password with an MD5 hash written into the database still works once (it is rehashed at the next login), but wp user update <user> --user_pass=<password> is the clean route. Password policies, expiry and breached-password checks come from plugins or from single sign-on. The hashing functions themselves are explained in PHP: Cryptography, Hashing and Passwords.

WordPress core has no two-factor authentication; it is added with a plugin or by delegating logins to an identity provider. The reference implementation is Two Factor, maintained by WordPress.org contributors, which provides authenticator-app (TOTP) codes, email codes and backup codes, with passkeys and security keys through a companion WebAuthn provider plugin. Many security suites (listed in Security plugins) include their own two-factor module, and SSO through SAML or OpenID Connect moves the second factor to the identity provider.

Source: Advanced Administration Handbook: Multi-Factor Authentication

Lumen Press requires a second factor for Administrators and Editors and enrolls two authenticators per administrator. A second factor protects the login form only; application passwords bypass it by design. The methods are explained in Authentication Methods: Passwordless and 2FA.

Application passwords (5.6+) authenticate REST API and XML-RPC requests with HTTP Basic authentication and never work on wp-login.php. They are shown once, stored hashed, listed per user and revocable one by one; creating, using and revoking them is covered in Users, Roles and Profiles. For hardening:

Source: Advanced Administration Handbook: Application Passwords

Core does not limit login attempts. Every attempt costs a full PHP request and a bcrypt verification, so the cheapest place to stop a password-guessing bot is in front of PHP: a CDN or WAF rule, or the web server. A login-limiting plugin also works but still pays the PHP cost of every blocked request. The official guidance adds strong passwords, two factors, protecting or disabling XML-RPC, temporary IP bans from log monitoring (Fail2ban is the usual tool), and warns that permanent country blocklists and HTTP Basic authentication on the whole of /wp-admin are unreliable or break AJAX and REST calls from the front end.

Lumen Press throttles wp-login.php in nginx with limit_req: a burst of three attempts, then six per minute per client address, answered with status 429. The same server block denies XML-RPC, blocks PHP in uploads and dotfiles, and adds the security headers discussed below:

Source: nginx: Module ngx_http_limit_req_module

nginx -t accepts the file in nginx:1.29 (1.29.8). With the same rules in front of the test site, six failed logins in a row returned 200 200 200 200 429 429, xmlrpc.php, a PHP file in uploads and /.git/config returned 403, and the error log recorded the throttling:

Source: Advanced Administration Handbook: Brute Force Attacks

Points to get right:

xmlrpc.php is the remote publishing API that predates the REST API: older versions of the WordPress mobile apps used it, as do desktop blog editors, pingbacks and some services such as Jetpack. It accepts a username and password in every request body, so it is a second login form without the protections that plugins add to wp-login.php.

Its system.multicall method used to be a brute-force amplifier: one request could carry hundreds of password guesses. Since 4.4 the first failed login in a request makes every later call in it fail; on the test site a multicall with a wrong password followed by the right one returned two Incorrect username or password. faults. One guess per request remains, so XML-RPC is disabled when unused and rate limited like wp-login.php when needed.

The xmlrpc_enabled filter is misleadingly named: returning false only disables the methods that need authentication. pingback.ping and the system.* methods keep answering. Disabling everything needs the xmlrpc_methods filter as well:

Source: Code Reference: xmlrpc_enabled

The results on the test site, saved as wp-content/mu-plugins/lumen-xmlrpc-off.php:

Source: Code Reference: xmlrpc_methods

The three system.* methods are built into the XML-RPC server class and cannot be removed by the filter, which is why denying xmlrpc.php at the web server, as in the nginx block above, is the stronger option. On Apache 2.4 the equivalent is a <FilesMatch "^(xmlrpc\.php|wp-config\.php)$"> section with Require all denied, placed above the # BEGIN WordPress marker so WordPress never rewrites it; on the test site both files then answered 403.

Since 7.1, pingbacks and trackbacks (outgoing and incoming, including pingback.ping) are disabled automatically in every environment type other than production; the wp_should_disable_pings_for_environment filter overrides it. Before disabling XML-RPC, check for Jetpack, desktop editors and integrations that still need it.

For day-to-day work (publishing, uploads, comments, new users, installing plugins), WordPress needs only SELECT, INSERT, UPDATE and DELETE on its own database. Schema changes during major updates, and plugins that create tables on activation, also need CREATE, ALTER, INDEX and DROP. The official handbook allows revoking the structural privileges but advises against it unless tested backups are in place, because a major update that cannot alter the schema fails half-way.

Lumen Press keeps two accounts: a runtime account for PHP with data privileges only, and a maintenance account that WP-CLI uses during updates and plugin activations. Neither has GRANT, FILE or privileges on other databases, and each site on the server has its own database and user:

Source: Advanced Administration Handbook: Hardening WordPress

wp-config.php reads the account from the environment, so the web server’s PHP-FPM pool gets the runtime account and the deployment shell exports the maintenance one:

Source: Advanced Administration Handbook: wp-config.php

As lumen_app, wp option update, wp post list and the front page worked on the test site, while creating a plugin table failed with "CREATE command denied to user"; it succeeded as lumen_maint. Plugin activation and wp core update-db therefore run as the maintenance account, which suits sites deployed from a pipeline (see Deployment and CI/CD). The database listens only on a private network.

Two constants in wp-config.php remove the dashboard’s ability to change code, which is what an attacker with a stolen Administrator session would use first:

On the test site, DISALLOW_FILE_EDIT removed only edit_plugins, edit_themes and edit_files from the Administrator; adding DISALLOW_FILE_MODS also removed install_plugins, update_plugins, delete_plugins and update_core, while activate_plugins remained.

Source: Advanced Administration Handbook: Disable File Editing

DISALLOW_FILE_MODS turns automatic security updates off as well, so a site that uses it needs its own process for applying them quickly (see Updates and Auto-Updates). Both constants are listed with the rest in wp-config.php Reference. They complement correct file ownership and permissions (644 for files, 755 for directories, 400 or 440 for wp-config.php, the web server writing only to wp-content/uploads where possible), which are explained in File Permissions and Filesystem. Uploads must never execute PHP: the nginx block above denies it, and on Apache a wp-content/uploads/.htaccess with a <FilesMatch "\.(?i:php[0-9]?|phtml|phar)$"> section containing Require all denied does the same (on the test site a PHP file in uploads went from 200 to 403).

The table prefix ($table_prefix, wp_ by default) is chosen at installation. A non-default prefix such as lp_ defeats some automated SQL injection payloads that hard-code the default table names; the handbook files it under "security through obscurity", since an injection can still read information_schema. Changing it later is risky for little gain: the <prefix>user_roles option and the <prefix>capabilities and <prefix>user_level user meta keys carry it too, and a missed one leaves every user without a role.

wp-config.php defines eight secrets: AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY and their *_SALT counterparts. wp_salt() combines them into the keys that sign login cookies and nonces. If a constant is missing or still holds the placeholder text, WordPress generates a value and stores it in the options table, which is weaker because a database leak then exposes it too.

Changing them invalidates every login cookie (everyone, including attackers holding a stolen cookie, is logged out) and every outstanding nonce. Rotate them:

New values come from https://api.wordpress.org/secret-key/1.1/salt/ or from WP-CLI:

Source: WP-CLI Commands: wp config shuffle-salts

On the test site, a logged-in Editor’s cookie loaded /wp-admin/profile.php with 200 before the command and was redirected to the login screen (302) after it. The session tokens stored in user meta survive, but no cookie matches them any more; they can be cleared per user with wp user session destroy <user> --all (WP-CLI 2.12.0 has no all-users flag, so a loop over wp user list --field=ID does it). shuffle-salts writes literal values into wp-config.php: on the official Docker image it replaced the getenv_docker('WORDPRESS_AUTH_KEY', ...) expressions, so sites that load secrets from the environment rotate them in the secret store instead.

WordPress 7.1.3 already sends X-Frame-Options: SAMEORIGIN and Content-Security-Policy: frame-ancestors 'self'; (send_frame_options_header()) plus Referrer-Policy: strict-origin-when-cross-origin (wp_admin_headers(), 4.9+) on wp-login.php and admin screens, and X-Content-Type-Options: nosniff on REST and admin-ajax.php responses. Front-end pages get none of them.

The front end, static files and uploads get their headers from the web server (the nginx block above, or Header always set on Apache), which covers every response including images and PDFs. On hosts without access to the server configuration, a must-use plugin covers the WordPress-generated pages through the wp_headers filter:

Source: Code Reference: wp_headers

On the test site the home page then carried all five headers.

Choosing and tuning the values:

Source: OWASP Cheat Sheet Series: HTTP Headers

CORS headers for the REST API are a different topic, covered in CORS.

A login name is half of a credential, and WordPress makes it easy to collect. The table shows what an anonymous visitor got from the test site, without and with the must-use plugin below:

Source: REST API Handbook: Users

Usernames are not secrets, and hiding them does not replace strong passwords, two factors and rate limits. Reducing the leak still removes the easy half of credential stuffing and keeps staff logins out of public lists. Lumen Press uses this must-use plugin:

Source: Code Reference: rest_endpoints

The plugin is saved as wp-content/mu-plugins/lumen-user-privacy.php. What the guard does not hide, by design:

Security plugins bundle several of the controls on this page with others that need a service behind them. The categories, rather than the brands, decide what a site needs:

Widely used plugins on WordPress.org, in alphabetical order, include Kadence Security (the plugin previously published as iThemes Security and, from version 9.0, Solid Security; renamed again in version 10.0), Limit Login Attempts Reloaded, Sucuri Security, Two Factor, Wordfence Security and WP Activity Log; several have paid tiers that add cloud firewalls, real-time rules or cleanup services. Vulnerability databases (Wordfence Intelligence, Patchstack, WPScan) also offer feeds and integrations independently of any plugin.

Choosing among them follows Choosing and Managing Plugins and Themes; a security plugin is itself code with vulnerabilities, and it adds a layer rather than replacing updates, backups or server rules.

The handbook’s monitoring page covers logs, uptime and performance; for security, Lumen Press adds:

Source: WP-CLI Commands: wp core verify-checksums

This is the test site after one core file was modified and one added (wp-config-docker.php comes with the Docker image). Extra files only produce warnings, so read them rather than the exit code. Themes and premium plugins have no published checksums; compare them with version control.

Signs of a compromise include browser or search warnings, a suspended account, unknown Administrators, spam pages, redirects only some visitors see, and unexpected outgoing mail. Document symptoms and times first, then:

Backups that make the clean-up possible are covered in Backups and Disaster Recovery.

Some popular advice adds work without adding security, or weakens it:

Further corrections across the whole sub-section are collected in Where Older Books and Tutorials Are Outdated.