Security Headers Checker
Free security headers checker. Grades HSTS, CSP, frame protection, nosniff, Referrer-Policy and Permissions-Policy, with every redirect and cookie flag.
Updated
A domain name or a full URL. A domain alone is checked over https://.
Enter a URL or a domain name, then select Check.
What Is a Security Headers Checker?
The security headers checker requests a web page and grades the HTTP response headers that tell browsers how to protect it. It scores six headers out of 100 points and gives a letter grade from A+ to F. It reads Content-Security-Policy directive by directive and names the directive that weakens it. It follows redirects and checks each one. It also lists deprecated headers, version numbers in server headers, cookie flags and the raw response headers. Cookie values are never shown.
How to Use the Security Headers Checker
- Enter a URL or a domain name. A domain without a scheme is checked over https://. The query string is not sent: the checker requests the origin and path only.
- Select Check. The checker requests the page, follows any redirects, and grades the last response.
- Read the grade and the line under it, then any warnings. Each scored header follows with its points; cookies, redirects and the raw headers open on demand.
- Copy the raw headers or the redirect chain, or copy a link that runs the same check.
How It Works
The checker sends one GET request to the URL from Cloudflare's network and reads the status and headers. It does not download the page body. It follows up to 5 redirects and checks every new address before requesting it. Each request carries a CF-Worker header with the name of the zone that runs the check, immunitysec.com.
Six headers earn points, 100 in total: Content-Security-Policy 30, Strict-Transport-Security 20, frame protection 15, X-Content-Type-Options 15, Referrer-Policy 10 and Permissions-Policy 10. A weak value earns half the points, rounded down. The weights and grade bands are this site's own rule, built on the headers the OWASP Secure Headers Project recommends.
The grade is A+ for 100 points with no warnings, A for 90 or more, B for 75 to 89, C for 60 to 74, D for 40 to 59 and F under 40. Browsers ignore Strict-Transport-Security on a response sent over HTTP, so a page served over HTTP gets no points for it and at most a D.
Strict-Transport-Security passes with a max-age of at least 31536000 seconds (1 year), the minimum the HSTS preload list accepts. A shorter max-age is weak, and max-age=0 turns HSTS off.
For Content-Security-Policy the checker reads the script policy: script-src, or default-src when there is no script-src, because default-src is the fallback for the other fetch directives. 'unsafe-inline' makes the policy weak only when the same directive has no nonce and no hash, because browsers ignore 'unsafe-inline' next to either. 'unsafe-eval' always makes it weak. A policy sent only as Content-Security-Policy-Report-Only reports violations without enforcing them and earns no points.
Frame protection passes with CSP frame-ancestors, or with X-Frame-Options set to DENY or SAMEORIGIN. When both are sent, browsers enforce frame-ancestors and ignore X-Frame-Options. ALLOW-FROM is not supported by modern browsers and counts as weak. Referrer-Policy passes when it is missing, because browsers then use strict-origin-when-cross-origin, and is weak only with unsafe-url.
Warnings cost no points but rule out A+. They cover X-XSS-Protection with a value other than 0, Expect-CT, Public-Key-Pins, a Server or X-Powered-By header that names a software version, and cookies without the Secure attribute. Cross-Origin-Opener-Policy, Cross-Origin-Embedder-Policy and Cross-Origin-Resource-Policy are shown but not scored, because the right value depends on which cross-origin windows and resources a site uses.
Points per Header
| Header | Points | What it does |
|---|---|---|
| Content-Security-Policy | 30 | Controls which resources, such as scripts, the browser may load for the page. |
| Strict-Transport-Security | 20 | Tells browsers to reach the host only over HTTPS and to upgrade later HTTP requests to HTTPS. |
| Frame protection | 15 | X-Frame-Options and CSP frame-ancestors control which pages may embed this one in a frame. |
| X-Content-Type-Options | 15 | With nosniff, the browser blocks a script or stylesheet whose MIME type does not match. |
| Referrer-Policy | 10 | Controls how much referrer information the browser sends with requests. |
| Permissions-Policy | 10 | Allows or denies the use of browser features in the document. |
Grades
| Grade | Points |
|---|---|
| A+ | 100 and no warnings |
| A | 90 or more |
| B | 75 to 89 |
| C | 60 to 74 |
| D | 40 to 59 |
| F | under 40 |
Warnings
| Header | Why |
|---|---|
| X-XSS-Protection (other than 0) | Modern browsers have deprecated X-XSS-Protection, and it can introduce security issues on the client side. OWASP recommends X-XSS-Protection: 0. |
| Expect-CT | Expect-CT is obsolete since June 2021. |
| Public-Key-Pins | All major browsers have deprecated Public-Key-Pins, and it is no longer recommended. |
| Server, X-Powered-By with a version | Detailed server software information can make known vulnerabilities easier to find. |
| Set-Cookie without Secure | Only a cookie with Secure is limited to HTTPS requests. |
Shown, Not Scored
| Header | What it does |
|---|---|
| Cross-Origin-Opener-Policy | Controls whether a window the page opens, or that opens it, shares its browsing context group. |
| Cross-Origin-Embedder-Policy | Controls how the page loads and embeds cross-origin resources requested in no-cors mode. |
| Cross-Origin-Resource-Policy | Asks the browser to block no-cors cross-origin or cross-site requests for the resource. |
| Set-Cookie: HttpOnly | HttpOnly keeps JavaScript, such as document.cookie, from reading the cookie. |
| Set-Cookie: SameSite | SameSite controls whether the cookie is sent with cross-site requests. Some browsers use Lax when it is missing. |
Standards
Scope
What It Checks
- +Grades Strict-Transport-Security, Content-Security-Policy, frame protection, X-Content-Type-Options, Referrer-Policy and Permissions-Policy out of 100 points, with a letter grade.
- +Reads Content-Security-Policy per directive and names the directive and source that make it weak, and treats 'unsafe-inline' next to a nonce or hash as ignored.
- +Follows up to 5 redirects, checks every redirect target before requesting it, and shows the chain.
- +Flags deprecated headers, software versions in Server and similar headers, and cookies without Secure or with broken __Secure- and __Host- prefixes.
- +Shows the raw response headers and cookie names and attributes, with every cookie value replaced by <redacted> before the result is cached or shown.
- +Requests only the origin and path of the URL, without the query string, and refuses private, loopback, link-local and reserved addresses, IP addresses, non-standard ports and URLs with a user name or password.
What It Does Not Check
- -It does not read policies set in the page HTML, such as a meta tag.
- -It does not download or run the page, so it does not see headers that scripts add to later requests.
- -It does not check the TLS certificate or the cipher suites.
- -It does not look up a domain's status on the HSTS preload list.
- -It does not publish or store a list of checked sites. Results stay in a server cache for 10 minutes.
Defensive Use
The OWASP Secure Headers Project publishes recommended values for response headers, such as max-age=63072000; includeSubDomains for Strict-Transport-Security and nosniff for X-Content-Type-Options. It also lists headers to remove because they reveal server details, such as Server and X-Powered-By. Comparing a live response with those lists shows which protections are missing and which headers give away more than they need to.
Frequently Asked Questions
What is a Security Headers Checker?→
The security headers checker requests a web page and grades the HTTP response headers that tell browsers how to protect it. It scores six headers out of 100 points and gives a letter grade from A+ to F. It reads Content-Security-Policy directive by directive and names the directive that weakens it. It follows redirects and checks each one. It also lists deprecated headers, version numbers in server headers, cookie flags and the raw response headers. Cookie values are never shown.
What is the Security Headers Checker used for?→
Checking a site after a deploy, a CDN or proxy change, or a new Content-Security-Policy, to see which security headers browsers actually receive and which one costs points.
Is my data sent anywhere?→
The Security Headers Checker sends the URL you enter to ImmunitySec servers, which run the check and return the result. To run it, they contact the site you enter, and Cloudflare's public DNS resolver to look up its address. Nothing else you enter leaves the page.
How is the Security Headers Checker used defensively?→
The OWASP Secure Headers Project publishes recommended values for response headers, such as max-age=63072000; includeSubDomains for Strict-Transport-Security and nosniff for X-Content-Type-Options. It also lists headers to remove because they reveal server details, such as Server and X-Powered-By. Comparing a live response with those lists shows which protections are missing and which headers give away more than they need to.
What max-age should Strict-Transport-Security use?→
The OWASP Secure Headers Project recommends max-age=63072000; includeSubDomains, which is two years. The HSTS preload list requires a max-age of at least 31536000 seconds, includeSubDomains and preload. hstspreload.org asks projects that give HTTPS advice not to add preload by default.
Why does 'unsafe-inline' not lower the grade when the policy has a nonce?→
When a CSP directive contains a nonce or a hash together with 'unsafe-inline', browsers ignore 'unsafe-inline'.
Should X-XSS-Protection still be sent?→
No. The OWASP Secure Headers Project says modern browsers have deprecated X-XSS-Protection and that it can introduce security issues on the client side. OWASP recommends X-XSS-Protection: 0 to turn the filter off, and Content-Security-Policy instead.
Why does a missing Referrer-Policy still pass?→
Without a valid Referrer-Policy, browsers use strict-origin-when-cross-origin. A policy is weak only with unsafe-url, which can leak private information from HTTPS URLs to insecure origins.
Does X-Frame-Options still matter if the CSP has frame-ancestors?→
When a response has both, browsers enforce CSP frame-ancestors and ignore X-Frame-Options. MDN recommends frame-ancestors instead of X-Frame-Options.
Header rules come from MDN Web Docs and the OWASP Secure Headers Project. The HSTS preload requirements come from hstspreload.org.