Security Headers Check
Security headers are instructions your server adds to every HTTP response, telling the browser to switch on protections it does not apply by default: block injected scripts, force HTTPS, refuse framing, stop MIME sniffing. Enter a URL and this checker fetches the final response, grades six headers out of 100 points, shows the exact value it found for each one, explains the risk in one line, and hands you the Nginx or Apache configuration to paste when a header is missing or weak. If you only want the quick version, the Website Health Check already includes a security-headers sub-score inside its overall report — this page is the deep dive: per-header grades and fixes, and nothing else.
Last updated:
Want this watched continuously? Monitor this free with myeventwatch — expiry and downtime alerts, no card required.
The deep dive, next to the health check’s quick score
The Website Health Check answers a broad question — is this site healthy overall? — and folds security headers into that answer as one sub-score among many. That is the right shape for a routine checkup, but it cannot tell you which header lost the points, what value your server actually sent, or what to paste into your configuration to fix it. This page exists for the follow-up work: one fetch, six scored headers, a letter grade, and for every header that is missing or weak, the precise Nginx and Apache lines that add or strengthen it. Nothing here is a black box — the full scoring table is published in the facts section below, and it is exactly the table the checker grades against.
How the check runs: the checker requests the URL you enter, follows redirects, and grades the headers of the final response — the response a browser would actually build the page from. It is a plain HTTP fetch, not a browser: no JavaScript executes, no sub-resources load, and headers that only appear on other paths or after login are not seen. The score measures one specific layer — whether these six browser-facing protections are present and strong — and nothing more. A site can score 100 and still carry an application bug; a site can score F and never have been breached. Treat the grade as a hardening checklist with weights attached, not as a verdict on the whole site’s security.
Fixing things, in impact order
Most of the score is cheap to win back. X-Content-Type-Options, frame protection and Referrer-Policy are one line each and break nothing on a normal site. Strict-Transport-Security is one line too, but send it only once every page and subdomain genuinely works over HTTPS — a year-long max-age is a promise browsers will hold you to. Permissions-Policy takes ten minutes of thought about which browser features your pages really use. Content-Security-Policy carries the most points and the most risk: deploy it first as Content-Security-Policy-Report-Only, watch the violation reports, fix what breaks, and only then enforce it. The companion guide, security headers, explained, walks through what each header actually stops and why the fix order above is the order it is.
Neighbouring checks: transport security is the other half of this story — the SSL grader scores the TLS configuration itself, while this page scores what the server says over that connection. For the broad routine checkup that includes headers alongside uptime, DNS and certificate expiry, go back to the Website Health Check.
A note on method: results are a snapshot of one fetch at one moment. CDNs and multi-server setups can answer different requests with different header sets, so a surprising result is worth one re-check before you change configuration — and worth checking again after the change, because a header added at the origin does not always survive the proxy in front of it.
The published scoring table
| Content-Security-Policy — 35 points | Good means an enforced policy (Report-Only does not count) that keeps scripts away from 'unsafe-inline' and 'unsafe-eval' and restricts where resources may load from. The heaviest weight, because CSP is the main defence against injected scripts. |
| Strict-Transport-Security — 20 points | Good means a max-age of at least one year (31536000 seconds) sent over HTTPS; includeSubDomains strengthens it further. Short max-ages earn partial points. |
| Frame protection — 15 points | Good means the CSP frame-ancestors directive or an X-Frame-Options header set to DENY or SAMEORIGIN, so other sites cannot embed your pages in a frame for clickjacking. |
| X-Content-Type-Options — 10 points | Good means the single value nosniff, so browsers cannot MIME-sniff a response into a different, executable type. |
| Referrer-Policy — 10 points | Good means a policy that never sends the full URL to other origins — strict-origin-when-cross-origin or stricter (same-origin, no-referrer). |
| Permissions-Policy — 10 points | Good means the header is present and switches off powerful browser features the site does not use, such as camera, microphone and geolocation. |
| Cross-Origin-Opener-Policy — bonus | Reported alongside the scored headers but worth no points: it isolates your pages from cross-origin windows, and sits outside the 100 on purpose, so the published weights stay exactly the six headers above. |
| Grades | 95 and above is A+, 90+ is A, 80+ is B, 65+ is C, 50+ is D, 35+ is E, and below 35 is F. Points are awarded per header according to the strength of the value found; a missing header scores zero for its row. |
Frequently asked questions
How is the score calculated — is it a black box?
No. Six headers carry fixed published weights — CSP 35, HSTS 20, frame protection 15, X-Content-Type-Options 10, Referrer-Policy 10, Permissions-Policy 10 — totalling 100. Each header earns full, partial or zero points depending on the strength of the value the checker found, and the letter grade follows the bands in the facts table above. Cross-Origin-Opener-Policy is reported as a bonus and never affects the score.
How is this different from the Website Health Check?
The Website Health Check is a broad checkup — uptime, DNS, TLS, expiry and more — in which security headers appear as one quick sub-score. This page grades only headers, but in depth: the exact value found for each one, a per-header verdict and points, the risk in plain language, and copy-paste Nginx and Apache fixes. Use the health check to spot the problem, this page to fix it.
Which response gets graded — mine has redirects?
The headers of the final response after all redirects are what is graded, because that is the response the browser builds the page from. The result shows the final URL and status so you can see where the chain landed. One caveat: this is a static fetch, not a browser — no JavaScript runs, so headers a framework only adds client-side, or that appear only after login or on other paths, are not part of the grade.
My site graded F. Does that mean it has been hacked?
No. An F means the final response carried few or none of the six scored headers — the common state of a default server or framework installation. It says your visitors’ browsers are not being given protections they could have; it says nothing about whether the site itself has been compromised. Work through the fixes in impact order and re-check: most sites can climb several grades in an afternoon.
Does a score of 100 mean my site is secure?
No — it means these six headers are present and strong on the checked URL. Headers are one hardening layer: they do not patch application bugs, weak passwords, outdated software or a broken TLS configuration. Pair this check with the SSL grader for transport and the Website Health Check for the broader picture.