WordPress security audit: every external check, its threshold, and what a failure costs

Why publish the rubric

Most security scanners hand you a padlock, a colour, and a grade. Green, "A", 82 out of 100. Where did the 82 come from? Which hole cost you 30 points and which cost 2? They will not say, because vagueness sells the upsell.

Here is the whole table instead. It is not a claim, it is a transcription of analyzeSecurity() in our engine, and every number below is the literal penalty in the code. Read the right-hand column as a priority list: a site served over plain HTTP loses more in one line than every missing header combined.

One thing I will say plainly up front, because it is the honest boundary of this tool: an external scan measures your exposure, not your compromise. It cannot tell you whether you have already been hacked. More on that in the limits section — read it before you trust a green score.

Transport: HTTPS and HSTS

HTTPS carries the single heaviest penalty on the whole page, 30 points, and I make no apology for it. In 2026 a WordPress site on plain HTTP is not a graded flaw, it is a broken site: every password and cookie travels in clear text, Chrome flags it, and Google will not rank it. The fix costs nothing — Let's Encrypt, ten minutes, most hosts do it with one click. HSTS is the follow-up: it tells the browser to refuse HTTP next time, closing the gap on that first insecure request.

HTTP security headers

The engine reads the response headers on your homepage and checks eight of them. A present header passes and costs nothing. A missing one deducts the amount below — and two of them (x-xss-protection, cross-origin-resource-policy) are reported for information only and never cost a point.

The whole header block can take at most 25 points off you, so do not obsess over it before the transport and file checks are green. CSP is weighted highest at 8 because it is both the most effective and the hardest to get right — a real Content-Security-Policy on a plugin-heavy WordPress site takes an afternoon of allow-listing, not a checkbox. The other five are a header your host or a plugin like Really Simple SSL adds in minutes. My honest take: get X-Content-Type-Options and X-Frame-Options in place today, and treat a full CSP as a project for the weekend you actually have time.

Information the server gives away

Neither of these is a vulnerability on its own — hiding your PHP version does not patch it. They are cheap points, though, and they matter because automated botnets scan by fingerprint: publish PHP/7.4.3 in your headers and you self-select into every scan looking for that exact version's known bugs. Removing the header is one line in your server config. It buys you 4 points and a quieter access log, not real protection. Do not mistake it for the latter.

Sensitive files left in the open

This is the part that finds real leaks. The engine sends a lightweight request to 20 known paths and, for each one that answers 200 OK, deducts points. Paths that would expose credentials or source are treated as critical (−8 each); the rest are warnings (−3 each). If nothing is exposed, the check passes and costs nothing.

The distinction is deliberate. /readme.html tells an attacker your exact WordPress version — annoying, worth 3 points. But a reachable /.env, a /.git/config that lets someone clone your whole source, or a /wp-config.php.bak that a text editor left behind hands over database credentials in plain text. That is not a "harden this" note, it is game over, and it is why those cost 8 and print as a hard fail. One caveat I will own: this list is 20 common names. If your backup is called site-backup-final-2.zip, an external scanner — ours included — will never find it. The only real defence is not putting secrets in the web root at all.

WordPress endpoints attackers hit first

Directory listing is the −10 because it is a genuine map of your install: leave /wp-content/plugins/ browsable and anyone can read off every plugin and version you run, then look each up against a vulnerability list. The fix is one line — Options -Indexes in .htaccess.

XML-RPC and user enumeration are the classic brute-force pair. xmlrpc.php lets an attacker try hundreds of passwords in a single request through system.multicall; ?author=1 hands them the usernames to try. Disable XML-RPC unless Jetpack or the mobile app needs it, and block author enumeration — most security plugins do both with a toggle. The login page is deliberately info only, zero points: renaming /wp-login.php is security through obscurity, mildly useful against dumb bots and not worth penalising a correctly-configured site over. We flag it so you know it is the default; we do not pretend it is a hole.

What this audit cannot see — read this before trusting a green score

An external scanner has hard limits, and a tool that hides them is selling you false comfort. Here is exactly what ours is blind to, none of which appears in a competitor's feature grid:

• Whether you are already compromised. This measures exposure, not infection. Injected spam links, a backdoor in a theme file, a malicious admin account — an outside scan sees none of it. For that you need file-integrity monitoring or a plugin like Wordfence scanning from the inside.
• Plugin and theme vulnerabilities. We do not match your plugin versions against a CVE database. A fully "green" site can be running a plugin with a critical known flaw. Keeping everything updated is the control this audit does not perform.
• The strength of your passwords and admin hygiene. Two-factor, weak passwords, dormant admin accounts — invisible from outside. A perfect header score does not stop a stolen password.
• Your wp-config.php contents. We check that backup copies are not exposed; we cannot read your actual salts, table prefix, or file-edit settings, because a correctly-served wp-config.php returns nothing.
• WAF and rate-limiting behaviour. We detect that xmlrpc.php is reachable; we do not fire a real brute-force run to see whether Cloudflare or a plugin would block it. Reachable is not the same as unprotected — it is a flag to check, not a verdict.
• The exposed WordPress version. That check exists, but it lives in the WordPress dimension of the report, not the security score, so it is not in the table above.

So a high security score here means your obvious external exposure is low. It does not mean you are safe. Treat it as the perimeter check it is, and pair it with an inside-out scanner for the rest.

The order to fix things, for WordPress specifically

Sorted by points-per-hour, which is the only ranking that respects your Saturday.

1. HTTPS (−30), ten minutes. If you are still on plain HTTP, stop reading and fix this. Let's Encrypt is free and most hosts enable it with one click. Everything else on this list is rounding error next to it.
2. Exposed .env / .git / wp-config backups (−8 each), minutes. If the file check flagged any of these, they are a credential leak, not a hardening task. Delete the file or block the path today, then rotate the database password if a wp-config copy was reachable.
3. Directory listing (−10), one line. Options -Indexes in .htaccess, or the equivalent in your nginx config. Stops attackers reading your plugin inventory.
4. HSTS (−8) and CSP (−8). HSTS is a single header and should follow HTTPS immediately. CSP is the afternoon project — worth it, but do it deliberately, testing that nothing on the page breaks.
5. XML-RPC and user enumeration (−5 each), one plugin. A security plugin disables both with two toggles. Skip XML-RPC only if Jetpack or the WordPress mobile app genuinely needs it.
6. X-Content-Type-Options and X-Frame-Options (−5 each), minutes. Two headers your host or an SSL plugin adds without you writing config.
7. The cheap fingerprint headers (−4, −4, −3, −2, −2). Hide X-Powered-By and the server version, add the remaining headers when convenient. Real points, marginal real safety — do them last.

My honest opinion, having watched this engine run against real WordPress sites: steps 1 to 3 are where actual risk lives, and everything below step 4 is score-tidying. A site that is HTTPS-only, leaks no files, and hides its directories has closed the doors that get most WordPress sites broken into. The headers make the report prettier; the first three keep you out of trouble.

Frequently asked questions