Skip to content
🚀 10 tools live, free forever — the toolbox keeps growing
Home›Tools›Security Tools›Security Headers Checker
Security Tool

Security Headers Checker

Check which security headers a site actually sends. The scan grades each one, and flags the ones that are present but weaker than they look, such as a CSP that still allows unsafe-inline or an HSTS with a short max-age.

Scan a site

Enter a domain. The check runs over HTTPS and reads only the response headers.

Result

Enter a domain to scan its security headers.

What gets checked

Content-Security-Policy30
Strict-Transport-Security25
X-Content-Type-Options10
Referrer-Policy10
Permissions-Policy10
Cross-Origin-Opener-Policy10
X-Frame-Options / frame-ancestors5
🛡️ Security Headers Checker

Security headers are instructions your server sends with every response, telling the browser what it may do with your page. They are configuration rather than code, so most are a single line, and they are the second line of defence that still holds when something upstream has already gone wrong. This checker fetches a site over HTTPS, reads the headers it sends back, and grades each one.

Key benefits

✓ Every header that matters, checked in one pass
✓ Weak settings flagged, not just missing ones
✓ A score you can re-check after each deploy
✓ Free, no signup, nothing stored

Common use cases

• Before a security review or a vendor questionnaire
• After changing your CDN, proxy or framework config
• Checking what a vendor or competitor actually sends
• Showing a team which header to add first

How to use it

  1. 1. Enter a domain, such as example.com. The scan runs over HTTPS and follows redirects to the address a visitor actually lands on.
  2. 2. Read the grade. It weights Content-Security-Policy and Strict-Transport-Security most heavily, because those two carry the most protection.
  3. 3. Work the weak ones before the missing ones. A CSP that allows unsafe-inline passes a naive check while stopping almost no XSS, which makes it the costliest kind of gap.
  4. 4. Deploy a change and scan again. Headers are per-response, so set them at your CDN or proxy and the whole site moves at once.

Key features

  • Every header that matters, checked in one pass
  • Weak settings flagged, not just missing ones
  • A score you can re-check after each deploy
  • Free, no signup, nothing stored
  • Before a security review or a vendor questionnaire
  • After changing your CDN, proxy or framework config

Rolling out security headers safely

Adding headers in the right order avoids breaking a working site.

Start with the low-risk headers

X-Content-Type-Options, Referrer-Policy and frame protection rarely break anything and can usually go live the same day.

Introduce HSTS gradually

Begin with a short max-age, confirm every subdomain works over HTTPS, then raise it to a year. Add preload only once you are certain.

Test the CSP in report-only mode

Deploy Content-Security-Policy-Report-Only first, watch the reports for a few days, then enforce the policy once nothing legitimate is blocked.

Recheck after every infrastructure change

A new CDN, proxy or hosting plan can drop headers without warning. Scan the site again after each change, and keep a copy of the last good result to compare against.

Frequently asked questions

What does the grade mean?⌄

It is a weighted score out of 100 across seven checks. Content-Security-Policy is worth 30 and Strict-Transport-Security 25, because those two carry the most protection; the smaller headers are worth 5 to 10 each. A header counted as weak earns part of its weight rather than none. A is 90 or above, B is 75, C is 60, D is 40.

Why does a header show as weaker than it looks?⌄

Because being present is not the same as being effective. A Content-Security-Policy that allows 'unsafe-inline' in script-src still lets an injected script run, and an HSTS with a one-day max-age protects almost nobody. Both would pass a check that only asks whether the header exists, so this one reads the value and says what is wrong with it.

Can I scan any website, or only my own?⌄

Any public site. Response headers are public information, sent to every visitor, so checking another domain reveals nothing that a browser would not already see. Only public hostnames are accepted; IP addresses and internal names such as localhost are refused.

Why can this not run entirely in my browser?⌄

Because CORS stops a page from reading another origin's response headers. A purely client-side version could only ever check the site it is already on, so the request is made server-side and the result is handed back as plain JSON.

Do you store the sites I scan?⌄

No. The result is cached for a few minutes so repeat lookups are instant and the site being checked is not hit again needlessly, and nothing else is kept. There is no account, no log of who scanned what.

📖
In-depth guide
HTTP Security Headers: A Complete Guide to CSP, HSTS and the Rest
Read the full guide →
Last updated: November 1, 2026
Share this page