XML-RPC security: three modes
XML-RPC accepts a username and password without ever showing a login form, so your lockout, CAPTCHA and two-factor step never see it. One request can also pack hundreds of password guesses together. WP SecureGate gives it three modes:
- Off: the endpoint refuses requests outright. Requests that Jetpack has taken over and signed are still let through, so a Jetpack connection keeps working.
- Authenticated-only: XML-RPC stays up for tools that need it, but every method that takes a password is removed and multi-call requests are refused.
- On: WordPress's normal behaviour.
Off by default. Pingback methods are removed in every mode except On.
Application passwords and user enumeration
Application passwords let a script sign in over the REST API, again without a second factor. Most sites never use them, so they are blocked. If a service you rely on connects this way, you can allow them again.
User enumeration is how an attacker learns which usernames to aim at: the REST users list and ?author= archive links both give names away. WP SecureGate closes both, which pairs with login security to make guessing harder from the first step.
Both blocked by default.
A WordPress security headers plugin, with care
Security headers tell browsers how to treat your pages. The safe, near-universal ones are sent from install, including X-Content-Type-Options, X-Frame-Options and Referrer-Policy.
HSTS and a Content Security Policy are opt-in. HSTS tells browsers to reach your domain only over HTTPS and to remember that. If your certificate later lapses, or a subdomain has no HTTPS, visitors can be locked out until the browser forgets, and you can't undo that from WordPress. A CSP can block your own scripts if it's written too tightly, so it has a report-only mode that shows what it would block before it blocks anything.
Safe headers on by default. HSTS and CSP off until you switch them on.
More WordPress security hardening: version and file editor
Hiding the WordPress version takes one easy clue away from automated scanners. Disabling the built-in file editor means a stolen admin session can't be used to type PHP straight into a theme or plugin file. The editor is left on until you choose, because some owners use it on purpose.
Version hiding is on by default. Disabling the file editor is off by default and included in Recommended.
File permissions, fixed and checked
A manual button tightens file permissions. wp-config.php is masked to at most 0640 (a stricter 0600 stays as it is), and every other file only loses world-write, so 0777 becomes 0775.
After each change WP SecureGate checks the new file mode, that PHP can still read the file, and that your home page still answers. If any check fails, it rolls the change back on its own. Each item also has a one-click undo. Files that PHP doesn't own are flagged so you can fix them in your hosting panel.
Manual. Nothing changes until you press the button.
Exposed files
Debug logs, backup archives and similar files are often left where anyone can download them. The malware scanner finds them. On Apache and LiteSpeed, "Block it now" writes a rule and confirms it works. On nginx, "Take it off the site" moves the file into quarantine, and the nginx rule is shown for you to add.
Found by the scan, which is on by default. Nothing is blocked or moved until you click.
Harden WordPress in one card
The Recommended settings card gathers the changes worth making on most sites into one list. Every item is ticked by default and you can untick any of them before applying. For 7 days afterwards, one click undoes the lot. The rest of the request-level protection lives in the WordPress firewall.
Offered, not applied. You choose what to apply.
Part of WP SecureGate: Firewall →