Why do I only see a few of these headers on a live-fetch check even though the site has good security?

Security headers like Strict-Transport-Security and X-Frame-Options are not part of the browser's CORS-safelisted response headers, so a cross-origin JavaScript fetch can't read them even when the server sends them correctly - the browser itself still enforces them, it just won't hand their values to page JavaScript. Paste headers copied from DevTools' Network tab (which shows what the server actually sent, unfiltered) or `curl -I` output for a fully accurate check.

Do I need both X-Frame-Options and CSP's frame-ancestors?

No - frame-ancestors is the modern replacement for X-Frame-Options and every current browser that supports CSP honors it; X-Frame-Options is a legacy fallback mainly useful for very old browsers. Having only frame-ancestors set is fine and this tool grades it as present either way, though sites that need to support ancient browsers sometimes keep both.

What's the practical risk of not having a Content-Security-Policy?

Without a CSP, if an attacker manages to get any script content into the page, e.g. through an unescaped form field, a compromised third-party ad, or a stored XSS bug, the browser will execute it with no restriction. A well-scoped CSP (restricting script-src to your own domain and known trusted sources) turns what would be a full XSS compromise into a blocked, logged violation instead.

Is a perfect 6/6 score required for a site to be considered secure?

No - these six headers are a strong baseline, not a complete security posture, and not every header applies equally to every site (a pure API with no HTML rendering has less use for CSP than a page rendering user content, for example). Treat a lower score as a prioritized list of gaps to review, not a pass/fail grade.

Security Headers Checker - HSTS, CSP, X-Frame-Options & More

Overview

Introduction

A handful of response headers do most of the work of telling a browser how strictly to defend a page: whether to force HTTPS, whether to run inline scripts, whether the page can be framed by another site. They cost nothing to add and most sites still ship without several of them, often simply because no one checked.

This tool checks a page's headers against six of the most commonly recommended baseline security headers, grades each one, and explains in plain language what each actually protects against, since "missing X-Frame-Options" means little without knowing clickjacking is the thing it prevents.

What Is Security Headers Checker?

A response-header security auditor that checks for Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options, X-Frame-Options (or CSP's frame-ancestors as its modern equivalent), Referrer-Policy, and Permissions-Policy.

Each header gets an individual present/missing/weak grade plus a plain-language note, and the six are rolled up into an overall "N/6 present" score badge.

How Security Headers Checker Works

Headers are read from either a live fetch or pasted text, parsed into name/value pairs, then each of the six checks looks up its target header case-insensitively and evaluates its value where the header's correctness depends on more than just presence (e.g. X-Content-Type-Options must specifically be "nosniff" to count as good).

For X-Frame-Options specifically, the check also looks for a frame-ancestors directive inside the Content-Security-Policy header, since that's the modern equivalent and either one satisfies the check.

When To Use Security Headers Checker

Before or after a security review, to get a quick baseline read on which of the six common headers a site is missing.

After adding a CSP or HSTS header, to confirm it's actually reaching the response and not silently dropped by a proxy, CDN, or load balancer in front of the origin.

Often used alongside HTTP Header Checker, Cache Header Checker and Redirect Checker.

Features

Advantages

Explains what each header actually defends against, not just whether it's present, so the results are useful to someone unfamiliar with the specific header.
Correctly treats CSP's frame-ancestors as satisfying the same protection as X-Frame-Options instead of falsely flagging a modern, correctly configured site as missing clickjacking protection.
Rolls results into a single at-a-glance score while still showing full per-header detail underneath.

Limitations

None of these six headers are in the CORS-safelisted response header set, so a live cross-origin fetch will typically show most or all of them as missing even on a well-configured site - the paste-headers path is the reliable way to check them.
This checks presence and basic correctness (e.g. nosniff spelled right), not policy quality - a Content-Security-Policy containing 'unsafe-inline' still counts as "present" even though it's meaningfully weaker than a strict policy.

Examples

A well-hardened response

Input

HTTP 200 OK
Strict-Transport-Security: max-age=63072000; includeSubDomains
Content-Security-Policy: default-src 'self'; frame-ancestors 'none'
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: geolocation=(), camera=()

Output

6/6 present (X-Frame-Options satisfied via CSP frame-ancestors)

All six checks pass; frame-ancestors 'none' in the CSP covers the clickjacking protection X-Frame-Options would otherwise provide.

A response with no security headers at all

Input

HTTP 200 OK
Content-Type: text/html; charset=utf-8
Cache-Control: no-cache

Output

0/6 present

Nothing in this response addresses HTTPS enforcement, XSS mitigation, MIME-sniffing, clickjacking, referrer leakage, or feature permissions.

Best Practices & Notes

Best Practices

Add Content-Security-Policy incrementally starting in Content-Security-Policy-Report-Only mode against real traffic before enforcing it, since an overly strict policy can silently break legitimate scripts or styles.
Set a long Strict-Transport-Security max-age (6 months or more) with includeSubDomains once you're certain every subdomain genuinely supports HTTPS, since HSTS has no per-request opt-out once a browser has cached it.

Developer Notes

The X-Frame-Options check treats presence of a frame-ancestors directive anywhere in the CSP header's raw string as satisfying the check via a simple /frame-ancestors/i regex test, not a full CSP directive parse; a CSP that mentions "frame-ancestors" only in a comment-like context would false-positive, though that's not realistic in a real header value.

Security Headers Checker Use Cases

Running a quick baseline security-header audit before a penetration test or compliance review
Verifying a newly deployed CSP or HSTS header actually reaches the browser through a CDN/proxy layer
Comparing header hardening between a marketing site and the main application, which often diverge because they're served from different infrastructure

Common Mistakes

Setting a security header at the application layer but having a CDN, reverse proxy, or load balancer strip or override it before the response reaches the browser.
Adding Content-Security-Policy-Report-Only during testing and forgetting to switch to the enforcing Content-Security-Policy header before launch, leaving the policy purely informational.

Tips

Check the same URL through your production CDN/edge, not just the origin server directly - headers set at the origin sometimes get dropped by an intermediate layer.

Security Headers Checker