Security Headers Checker

What are HTTP security headers?

HTTP security headers are response headers that web servers send to browsers to enable security features. They protect against common attacks like cross-site scripting (XSS), clickjacking, and protocol downgrade attacks.

Which security headers are most important?

Content-Security-Policy (CSP) and Strict-Transport-Security (HSTS) are the most critical. CSP prevents XSS attacks by controlling which scripts can execute. HSTS forces HTTPS connections, preventing man-in-the-middle attacks.

What this tool checks

We grade 10 HTTP response headers that browsers use to enforce security boundaries: Content-Security-Policy (CSP) blocks injected scripts and inline event handlers that cause most XSS. Strict-Transport-Security (HSTS) forces HTTPS, including the preload-list eligibility check. X-Frame-Options and the frame-ancestors directive in CSP block clickjacking from arbitrary iframes. X-Content-Type-Options stops MIME-sniffing attacks where a server's mislabeled response is reinterpreted as a different type. Referrer-Policy controls what URL data leaks to third parties when users click outbound links. Permissions-Policy denies cameras, microphones, geolocation, payment, and seven other powerful browser APIs unless the page explicitly requests them. Cross-Origin-Opener-Policy isolates your browsing context from window.opener leaks. Cross-Origin-Embedder-Policy and Cross-Origin-Resource-Policy together gate the SharedArrayBuffer and high-resolution timer APIs that Spectre-class side-channel attacks exploit. Each header is checked for presence, value correctness against the current spec, and alignment with best-practice — for example, an HSTS header with a one-year max-age but no includeSubDomains scores lower than a two-year max-age with preload.

How we grade the results

Each header receives one of three grades: pass (present with a correct, current-best-practice value), warning (present but with a value that is outdated, insufficient, or contains a known weakness), or critical (missing entirely in a context where it should be set). The weighting reflects real-world impact: missing CSP and HSTS on a production HTTPS site are the most severe findings, while a missing Permissions-Policy on a static marketing page is a warning rather than critical. We do not penalize headers that are intentionally absent for a documented reason — for example, X-Frame-Options is now redundant when a CSP frame-ancestors directive is set, and we credit the CSP path. The scoring also adapts to the response: a 301 redirect that ships only the minimum subset of headers is treated differently from a 200 HTML response that should carry the full set. All grading rules are deterministic and visible in the source repository, and the same evaluator runs across both this free tool and the full audit pipeline so results are consistent either way.

Common findings on real sites

Across thousands of public scans, four patterns repeat. First, missing Content-Security-Policy is the most common critical finding — more than half of audited sites ship no CSP at all, leaving inline scripts and event handlers vulnerable to XSS injection. Second, HSTS is often present but configured weakly: a max-age below six months, missing includeSubDomains, or absent from the preload list — meaning the first visit to a subdomain still happens over plaintext. Third, X-Content-Type-Options: nosniff is missing on a surprising number of API responses, allowing MIME-sniffing attacks where a JSON endpoint is reinterpreted as JavaScript by a malicious referring page. Fourth, Permissions-Policy is the newest header and the least adopted: most sites do not deny access to the 10+ powerful browser APIs even when they never use any of them, leaving an XSS-compromised page free to silently activate the user's microphone or geolocation. A site that passes all four checks ends up in the top 5% of the public scan corpus, which is a much stronger signal than a single header grade in isolation.

How to add the missing headers

Most security headers are one line to add. For Nginx, set them in the server or http block with the add_header directive — for example: add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always. The 'always' parameter is important — without it, Nginx skips the header on non-200 responses, leaving error pages unprotected. For Apache, use Header set inside a Directory or VirtualHost block. For Express.js, the helmet middleware sets the full security-header set with sensible defaults in three lines: install helmet, require it, and add app.use(helmet()) before any route. For Cloudflare, the Transform Rules dashboard exposes every header without redeploying — useful for setting CSP and HSTS on origins you do not control. The trickiest header is Content-Security-Policy: a wrong value breaks the page silently, so always start in report-only mode (Content-Security-Policy-Report-Only) for at least a week before switching to enforcement. Use the report-uri or report-to directive to collect violation reports, fix what your application legitimately needs, then promote to enforcing mode. The CSP details panel in this tool's report breaks each directive out separately so you can see exactly which sources your site allows today.

Why these headers actually matter

Security headers are the lowest-effort, highest-impact defense most sites can deploy — they cost nothing to add and they neutralize entire classes of attack at the browser boundary, before your application code runs. CSP turns XSS from a near-total compromise into a logged violation report you can investigate at leisure. HSTS prevents the SSL-stripping attacks that defeat HTTPS on hostile networks, including the rogue Wi-Fi access points common at conferences and coffee shops. X-Frame-Options and frame-ancestors block clickjacking, where an attacker embeds your authenticated UI in a transparent iframe and tricks users into clicking destructive actions. The Cross-Origin trio (COOP, COEP, CORP) was added specifically to mitigate Spectre and Meltdown speculative-execution side channels — without them, a malicious cross-origin embed can read your tab's memory through timing attacks. Permissions-Policy is the youngest header but arguably the most important: a single XSS bug in a page that explicitly allows camera access lets an attacker turn the user's webcam on without UI feedback. None of this replaces other defenses (input validation, parameterized queries, dependency hygiene), but it does buy enormous defense-in-depth at near-zero implementation cost.