How to use the security headers checker
- Enter a page URL and press Check headers. Redirects are followed and the final response is analysed.
- Start with the fix-first list, then open the Content Security Policy group to see each directive and its sources; red badges mark unsafe-inline, unsafe-eval and wildcards.
- Read the explanation under each finding to decide whether it applies to your site; not every header suits every page.
- Copy the suggested value for any missing header, adapt it (especially CSP) and re-check after deploying.
Features
- Full CSP directive table for enforced and report-only policies, with fallback logic (default-src) applied the way browsers do
- HSTS parsed into max-age, includeSubDomains and preload with thresholds for six months and one year
- Referrer-Policy values explained individually, Permissions-Policy features listed, X-Frame-Options and frame-ancestors combined into one framing verdict
- Cross-Origin-Opener-Policy, Cross-Origin-Embedder-Policy and Cross-Origin-Resource-Policy
- Set-Cookie flags per cookie (Secure, HttpOnly, SameSite, __Host-/__Secure- prefixes) with values discarded
- Cache-Control on HTML, Access-Control-Allow-Origin with credentials, Server and X-Powered-By exposure
- Copy-ready example values for whatever is missing, plus the raw header list and a plain-text report
What the headers do
Strict-Transport-Security tells a browser that has seen it to use HTTPS only, for the stated number of seconds. Content-Security-Policy restricts where scripts, styles, images, frames and connections may load from, which is the strongest browser-side defence against cross-site scripting; script-src is the directive that matters most, and nonces or hashes beat host allow-lists. X-Content-Type-Options: nosniff stops browsers from guessing content types. X-Frame-Options and frame-ancestors decide who may embed the page, which prevents clickjacking. Referrer-Policy limits what the Referer header reveals to other sites. Permissions-Policy switches off browser features the page does not need.
Cross-Origin-Opener-Policy isolates the window from cross-origin openers, Cross-Origin-Embedder-Policy and Cross-Origin-Resource-Policy control what may be embedded and by whom. On cookies, Secure keeps them off plain HTTP, HttpOnly hides them from scripts and SameSite limits cross-site requests that carry them. Cache-Control matters when personalised HTML could be stored by a shared cache, and Access-Control-Allow-Origin decides which sites may read the response with JavaScript.
Reading the CSP table
Each row is one directive with its source list. 'self', 'none', nonces, hashes and 'strict-dynamic' are shown in green; 'unsafe-inline', 'unsafe-eval', bare schemes like https: and the * wildcard are shown in red because each of them widens what an injected script can do. When a fetch directive such as img-src is absent, browsers fall back to default-src, and the analysis does the same. Browsers ignore 'unsafe-inline' when a nonce or hash is present in the same directive, so that combination is reported as informational rather than as a failure.
Limitations and responsible use
One anonymous GET request from a single server, without JavaScript, without cookies and without an Origin header. Headers that depend on login state, on the request's Origin (reflected CORS) or on the user agent cannot be seen, so a clean result is not proof that the site is well configured in every situation. Only test sites you own or are authorised to test.
- Header values are kept up to 8 KB; anything longer is truncated with an ellipsis.
- Only the final response after redirects is analysed. Intermediate hops can lack headers that matter (for example HSTS on the http:// hop).
- Private addresses, non-standard ports and credentials in the URL are refused.