WordPress Security Headers Check
The six security headers, what each one does, whether http redirects to https, and what the server publishes about itself. Passive: nothing is probed.
This tool needs JavaScript: the server makes the request, because a browser cannot read the response headers of another site.
One request to the home page over https, and one over http to see whether it redirects. Nothing else is touched.
This is one of the few tools here that asks the server rather than your browser, because a browser cannot do it. Nothing you put in is stored; the request is rate limited by address and the answer is not cached.
The backlog called this a security scanner. It is not one, and the rename is the point: anything worth calling a scan means probing paths on a site the person running it may not own, and a tool that does that to any address a stranger types is a tool for attacking sites.
What a stranger can check politely is the headers, and those are worth checking. They are cheap to add, most sites are missing several, and they decide how much damage a successful injection can do.
How to use
Put in a domain. One request goes to the home page over https, and one over http to see whether it redirects. Nothing else is touched.
Example
Site https://example.com/
Status 200
Security headers
strict-transport-security max-age=31536000; includeSubDomains
content-security-policy not sent
what it does says which sources may load scripts and styles: the one
header that limits what an injected script can do
x-content-type-options nosniff
referrer-policy strict-origin-when-cross-origin
permissions-policy not sent
x-frame-options SAMEORIGIN
What the server tells everybody
server nginx
generator tag WordPress 6.8.1 ← publishes the version to anybody scanning
http, which is what a typed address uses
ends at https://example.com/ ← redirected to https
2 of the 6 headers above are missing.Pitfalls
Headers are not security. They limit what goes wrong after something else has. Updates, passwords, user roles, backups and what your plugins do with input are where the risk actually lives, and none of it is visible from outside.
A CSP with unsafe-inline permits the thing it exists to stop. It is extremely common on WordPress,
because themes and plugins print inline scripts. Getting off it is a project; knowing you are on it is
the start.
HSTS with a short max-age does very little. Six months is the usual minimum and preload lists want a year. An hour, which is a common copy-paste default, protects almost nobody.
The generator tag publishes your version. It is one line in functions.php to remove, and it is the difference between a scanner trying everything and a scanner knowing what to try.
X-Powered-By is the same problem with less excuse. Turn it off at the server.
Cookies on a page with no login should still be marked. Secure, HttpOnly and SameSite cost nothing and are routinely missing from analytics and consent cookies.
Missing headers are not an emergency. Add them in order: HSTS once https works properly,
X-Content-Type-Options and Referrer-Policy next because they are one line each, CSP last because it
is the one that breaks things.
A “security score” from any tool is a headline, not a finding. This counts the missing headers and says nothing about how secure the site is, because it cannot know.
Compatibility
Two requests: the home page over https, and the same page over http to see the redirect. That is exactly what a browser does when somebody types the domain, which is why it is fair game.
Deliberately not done: probing paths such as wp-admin, wp-login.php, readme.html or xmlrpc.php;
testing plugin or theme versions against a vulnerability list; anything resembling a port scan. The
output says so, because a tool that quietly does more than it claims is worse than one that does less.
The address goes through the same guard as every other server tool: http and https only on the standard ports, the name resolved first with private and reserved addresses refused, redirects followed by hand with the checks repeated on each hop, responses capped. Rate limited to 20 requests a minute per address, with nothing stored.
The headers checked are Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options,
Referrer-Policy, Permissions-Policy and X-Frame-Options — and X-Frame-Options is reported as unnecessary
rather than missing when the CSP sets frame-ancestors, which supersedes it.
Frequently asked questions
Why not check for vulnerable plugins?
Which header should I add first?
X-Content-Type-Options: nosniff and a Referrer-Policy: one line each and nothing breaks. Then HSTS
once you are certain https works everywhere. CSP last, and with a report-only policy first.Will a CSP break my site?
Content-Security-Policy-Report-Only is for: run it, collect the
reports, fix what fires, then enforce.