HTTP Security Headers Analyzer
Grade a site's security headers — CSP, HSTS, X-Frame-Options, and more — with a plain-English reason behind every point.
Also known as: Security headers checker, HTTP header grader, CSP analyzer, Website security header scanner
How it works
- 1Enter a URL or domain to analyze.
- 2Review the letter grade and per-header point breakdown.
- 3Read each header's explanation to understand what's missing or weak.
- 4Check the cookie flags panel if the site sets any cookies.
Why use HTTP Security Headers Analyzer
Points-based scoring, not just pass/fail
A weakened CSP or a short HSTS max-age gets partial credit, not a false all-or-nothing result.
Understands header interactions
Correctly treats CSP's frame-ancestors as covering clickjacking protection even when X-Frame-Options is absent, matching real browser behavior.
Checks cookie flags too
Reports Secure, HttpOnly, and SameSite on every cookie the site sets — not just the response headers.
Verified against real sites
Scoring logic checked against captured real-world headers from major sites, not just synthetic test cases.
Every point explained in plain English
No header check is a black box — each one states exactly why it scored what it did.
Clearly discloses the one server-side step
Fetching another site's headers has to happen server-side; that's labeled plainly, and nothing about the page is kept afterward.
Who uses HTTP Security Headers Analyzer
Auditing your own site's security headers
Get a concrete letter grade and a prioritized list of what to add or fix before a security review.
Checking headers after a CDN or hosting migration
Confirm headers configured at the old host actually carried over correctly to a new one.
Comparing a staging environment against production
Spot-check that security headers match between environments before a deploy.
Evaluating a vendor or third-party site
Get a quick read on a partner or vendor's basic security posture before integrating with them.
Learning what each security header actually does
See a live example graded with a plain-English explanation for each header, rather than reading documentation alone.
Verifying a CSP change didn't accidentally weaken protection
Check that a new Content-Security-Policy doesn't introduce 'unsafe-inline' or drop a directive by mistake.
About HTTP Security Headers Analyzer
Security headers are one of the highest-leverage, lowest-effort defenses a website can add — a single response header can rule out entire categories of attack (clickjacking, MIME-sniffing, some XSS vectors) without touching a line of application code. And yet they're consistently under-deployed, often because it's not obvious which headers matter, what a "good" value actually looks like, or how they interact with each other.
This tool fetches a URL's response headers server-side (a browser tab can't reliably read another origin's response headers directly) and scores nine of them — Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy, and the three Cross-Origin-* isolation headers — against a points-based rubric, weighted by how much protection each one actually provides.
The scoring isn't just presence-or-absence. A Content-Security-Policy that's present but allows 'unsafe-inline' gets partial credit, not full marks, since that significantly weakens what CSP is meant to prevent. An HSTS header with too short a max-age gets flagged. X-Frame-Options is correctly treated as redundant (not missing) when a CSP frame-ancestors directive is already doing that job, since that's how real browsers resolve the overlap. Cookies are checked separately for Secure, HttpOnly, and SameSite flags, since a strong header policy doesn't help much if session cookies are still exposed.
One honest caveat: the CSP check scans the whole policy string for 'unsafe-inline'/'unsafe-eval' rather than distinguishing which specific directive they appear in — a site with 'unsafe-inline' only in style-src (a much smaller risk than in script-src) will still show a warning here rather than full marks, a deliberately conservative simplification rather than a false positive.
HTTP Security Headers Analyzer vs. other options
How Open Tools Library compares to desktop software and other online tools.
| Feature | Open Tools Library | Desktop software | Other online tools |
|---|---|---|---|
| Price | Free, unlimited | N/A | Often free |
| Scoring granularity | Points-weighted per header with partial credit | N/A | Often simple pass/fail |
| Header interaction awareness | Understands CSP frame-ancestors supersedes X-Frame-Options | N/A | Varies |
| Cookie flag checking | Included for every Set-Cookie header | N/A | Not always offered |
| Explanation depth | Plain-English reason for every point awarded or lost | N/A | Often just a grade with no detail |
| Data retention | Page body discarded immediately, nothing stored | N/A | Varies |
Pro tips
- A Content-Security-Policy containing 'unsafe-inline' anywhere in the string is flagged as a warning here, even if it's only in a lower-risk directive like style-src — treat the result as a starting point for closer review, not the final word.
- X-Frame-Options being absent isn't automatically a problem if CSP's frame-ancestors directive is present — modern browsers use frame-ancestors and ignore X-Frame-Options when both are set.
- HSTS only matters over HTTPS — if a site is checked over plain HTTP, this tool marks HSTS as "not applicable" rather than falsely flagging it as missing.
- Missing Permissions-Policy and Cross-Origin-Embedder-Policy are common even on well-configured, high-traffic sites — they're genuinely under-adopted headers, not necessarily a sign of neglect.
Technical specs
- Headers checked
- CSP, HSTS, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy, COOP, CORP, COEP
- Cookie flags checked
- Secure, HttpOnly, SameSite on every Set-Cookie header
- Scoring
- Points-weighted per header, mapped to an A+ through F letter grade
- Redirects
- Up to 5 hops followed, each re-validated for safety
- Fetch scope
- Headers only — the page body is discarded, never analyzed or stored
- Processing location
- Server-side fetch (disclosed) — required to read another origin's response headers reliably
Privacy & security
Checking a site's response headers doesn't require keeping anything about the site afterward.
Only the response headers are read — the page body is discarded immediately, never stored or analyzed.
The fetch is unauthenticated and one-off; nothing is cached or logged after the result is returned.
No account, no email, no login — just a URL in, a grade out.
Equally private whether you're checking your own site or someone else's public headers.
Frequently asked questions
Why does fetching headers need to run server-side?
Browsers restrict reading another origin's response headers directly from a web page for security reasons — a server-side fetch is the reliable way to read them completely and consistently.
Is the page's content stored or analyzed?
No — only the response headers are read and scored. The page body is discarded immediately after headers are captured.
What scoring rubric does this use?
A points-weighted system based on the OWASP Secure Headers Project baseline — a distinct rubric built for this tool, not a copy of any other specific scoring tool's algorithm.
Why is Permissions-Policy weighted the same as X-Frame-Options?
Both are meaningful but address different risks — the weighting reflects how much protection gap each header's absence typically represents, not how well-known the header is.
Does a perfect score mean the site has no other security issues?
No — this only evaluates HTTP response headers. It says nothing about the site's application code, authentication, or other security practices.
Can I check a URL that requires login?
No — the fetch is unauthenticated, so it sees only what a logged-out visitor's browser would see in response headers.
Troubleshooting
Why did my CSP get marked down when script-src looks fine?
The check scans the entire policy string for 'unsafe-inline'/'unsafe-eval', not just script-src — if either appears anywhere (including style-src), it's flagged as a warning rather than full marks, a deliberately conservative simplification.
X-Frame-Options shows as missing, but I have frame-ancestors in my CSP
That's actually scored as good — frame-ancestors supersedes X-Frame-Options in modern browsers, so the check treats the site as protected even without the older header present.
HSTS shows "not applicable" instead of missing
The site was reached over plain HTTP — HSTS only has meaning over HTTPS, so it can't be meaningfully evaluated and isn't penalized as if it were simply forgotten.
The URL I entered failed to fetch
The target may be unreachable, may have redirected too many times, or may point to a private/internal address that's blocked for safety — the error message will indicate which.
Related searches
Landed here looking for something worded a little differently? HTTP Security Headers Analyzer covers all of these too:
Ready to use HTTP Security Headers Analyzer?
Free, private, and ready right now — no signup required.
Scroll to HTTP Security Headers Analyzer