HTTP Security Headers Checker

A browser makes several security decisions before it displays a page, runs a script, stores a cookie, or lets another origin read a response. HTTP response headers are the policy lines that carry many of those decisions. They sit before the body, so a clean-looking page can still be missing a transport rule, an embedding rule, a cache rule, or a cookie attribute that changes how safely the browser handles the response.

Security headers are not a replacement for fixing vulnerable code. A weak script policy cannot be repaired by a good referrer policy, and a strong HSTS setting does not prove that session cookies are scoped correctly. Their value is narrower and still important. They ask the browser to enforce boundaries that reduce common damage paths such as downgrade exposure, clickjacking, MIME sniffing, loose cross-origin reads, overly revealing referrers, and cached sensitive pages.

The hard part is scope. Headers are attached to one response, not magically to an entire site. The final HTML document, the HTTP-to-HTTPS redirect, an error page, a JSON endpoint, a static script file, and an authenticated account page may all be produced by different server layers. CDN rules, reverse proxies, application defaults, and route-specific middleware can also change headers after the application has already rendered the response.

Header names can sound more absolute than they are. Content-Security-Policy may be present but report-only, too broad, or missing the directives that stop framing and plugin content. Strict-Transport-Security depends on HTTPS delivery and a sensible max-age. Set-Cookie needs attributes that match the session risk. Access-Control-Allow-Origin: * may be acceptable for a public, credentialless API and risky for personalized data.

The practical aim is not to collect every possible header. It is to confirm that the response a browser actually receives carries policies that match the content, the route, and the data sensitivity. Repeated checks across important response variants usually reveal more than a single pass against a long header checklist.

How to Use This Tool:

Paste one raw response header block at a time, then choose the response profile and observed response type that match the capture. The checker grades pasted evidence rather than fetching the site itself, so the result is only as accurate as the header block you collected from the path under review.

1. Enter a short Target label such as a hostname, route, release name, redirect hop, or environment. The label appears in exported evidence.
2. Choose Response profile. Use Browser document for normal HTML pages, Sensitive app page for account or admin content, JSON or API response for machine-facing responses, and Static asset response for cacheable files.
3. Set Observed response to Final HTTPS response, Plain HTTP response, or Redirect hop. This choice changes how HSTS and context-dependent findings are judged.
4. Paste the header block into Response headers, drop a text capture onto the field, or use Browse TXT. Keep repeated Set-Cookie lines as separate lines, remove request headers, and remove the response body.
5. Check Header parsing notes before trusting the result. Missing colons, folded lines, duplicate non-cookie headers, and accidental body text can change the evidence.
6. Review Header Scorecard for every control, then use Remediation Queue to work from the highest-priority fail and warning rows.
7. Open Header Inventory when you need the parsed values, Header Posture Map when you need category-level score loss, and JSON when you need a portable record of the assessment.

The hardened and weak samples are useful for learning the scoring model. Replace them with captured headers before using the result for a release review, vendor check, audit note, or remediation ticket.

Interpreting Results:

The grade is a summary, not a release decision. A single high-priority fail can matter more than a high score because missing HSTS, a report-only CSP on a browser document, weak cookie attributes, missing framing protection, or credentialed wildcard CORS can expose a specific attack path. Start with Fail rows, then work through Warn rows that match the response's sensitivity.

Some results are deliberately context-sensitive. Missing CSP is more serious for a browser document than for a pure API response, while wildcard CORS is treated more cautiously outside an API context. Sensitive pages receive stronger cache scrutiny because stored personalized responses can remain available through browser history, shared machines, intermediaries, or misconfigured CDN behavior.

A clean header result does not prove that the application is secure. It means the pasted response avoided the checked header problems under the selected profile. Live browser testing, cookie scope review, CSP violation reports, authentication checks, dependency review, and application security testing remain separate work.

Technical Details:

Security headers work because browsers attach enforcement behavior to specific response fields. HSTS changes future transport decisions after a valid HTTPS response. CSP constrains resource loading, inline script behavior, plugin content, base URL handling, and frame embedding. MIME sniffing protection asks the browser to trust the declared content type instead of guessing. Referrer policy limits how much URL detail leaves the origin. Cookie attributes influence whether session cookies travel over HTTPS, remain hidden from client-side scripts, and join cross-site requests.

The most important technical boundary is response scope. Headers are not global site properties unless every relevant response emits them consistently. A CDN may add HSTS to one route, an application server may add cookies on another, and an object store may serve static files with different cache and content-type rules. Header reviews should be read as evidence about one captured response and then repeated across the paths that carry different content or security assumptions.

Rule Core

The checker uses ordered rule checks for the header areas that most often change browser security posture. The table below summarizes the main signal and the kinds of values that trigger attention.

Score Core

Each checked control becomes a Pass, Warn, Fail, or Info row. Failing rows subtract their full priority weight, warning rows subtract 45 percent of their priority weight, informational rows do not change the score, and passing rows can add small bonuses when they show extra hardening evidence.

P is the sum of priority weights for Fail rows, W is the sum of priority weights for Warn rows, and B is the sum of passing bonuses. The score is rounded to the nearest whole number and capped between 0 and 105. Bonuses are deliberately small: HSTS with preload evidence can add 2 points, a stronger cross-origin isolation combination can add 1 point, and complete CSP reporting evidence can add 1 point.

For example, one high-priority failure and two medium-priority warnings subtract 20 + 0.45 x 24, or 30.8 points before rounding and bonuses. A preload-ready HSTS policy may add a small bonus on a different run, but it does not cancel the need to fix the failed control that created a concrete browser-risk gap.

Parsing and Evidence Boundaries

The parser accepts an optional HTTP status line followed by name: value fields. Folded continuation lines are joined with a warning, malformed lines are ignored with a warning, repeated non-cookie headers are flagged because browsers or intermediaries may combine or override them, and repeated Set-Cookie fields are preserved as separate cookie evidence.

A pasted capture is still a snapshot. It does not prove that a different CDN edge, response variant, localization path, error handler, authenticated route, or browser cache state sends the same headers. Use repeated captures from representative paths when the result will drive production changes.

Privacy and Accuracy Notes:

Pasted response headers are parsed in the browser. The header text is not submitted for analysis unless you separately share, copy, download, or upload the exported evidence somewhere else.

Header captures can still reveal sensitive operational details. Hostnames, internal route names, cookie values, platform banners, cache behavior, CSP hosts, reporting endpoints, and infrastructure clues may be present in the pasted text or exported files. Redact secrets and session values before attaching results to tickets, email, or external audit evidence.

The checker evaluates header posture, not exploitability. A missing header may be low impact on one response and serious on another, while a passing header can still hide a weak application pattern. Treat the result as a prioritized header review and combine it with live browser behavior, CSP reports, server configuration review, and application testing.

Worked Examples:

Hardened production document

A final HTTPS browser document includes durable HSTS with includeSubDomains, an enforced CSP with nonce-based scripts, object-src 'none', base-uri 'none', and frame-ancestors 'none', plus X-Content-Type-Options: nosniff, a strict referrer policy, denied sensitive browser features, explicit no-store caching, protected session cookies, and CSP reporting. The response can reach A+ with no Fail rows. The next check should cover route variants rather than adding more header names to the same capture.

Sensitive page with weak session headers

A sensitive account page has no HSTS, a report-only CSP, X-Content-Type-Options: sniff, Referrer-Policy: unsafe-url, missing framing protection, a session cookie without Secure or HttpOnly, and no cache policy. Several high and medium priority rows fail or warn, so the score can fall to F. Splitting the remediation into transport, CSP, cookie, and cache changes usually makes the fix safer to review.

API response with public CORS

A public JSON response uses Access-Control-Allow-Origin: *, sends no cookies, and is reviewed as JSON or API response. Wildcard CORS can be acceptable for intentionally public credentialless data, but missing HSTS, missing nosniff, or unclear cache rules still affect the score. Confirm the endpoint never returns personalized data before accepting the wildcard.

Messy terminal paste

A copied terminal capture includes headers, blank lines, and a fragment of the response body. Header parsing notes reports ignored lines. Clean the input to a single response header block, preserve repeated Set-Cookie lines, and rerun before comparing the result to a previous release.

FAQ:

Glossary:

HSTS

HTTP Strict Transport Security, a response header that tells browsers to use HTTPS for future requests to the same host for a declared time period.

CSP

Content Security Policy, a browser policy for restricting resource loading, script behavior, base URL handling, framing, and reporting.

CORS

Cross-Origin Resource Sharing, the browser mechanism that decides whether another origin may read a response.

MIME sniffing

Browser behavior that guesses a resource type from bytes; nosniff asks the browser to rely on the declared content type.

Report-only CSP

A CSP mode that records policy violations without blocking the browser action that caused them.

SameSite

A cookie attribute that controls whether a cookie joins cross-site requests under Lax, Strict, or None behavior.

Posture map

The chart that groups weighted security-header findings into category score and penalty percentages.

References:

• HTTP Security Response Headers Cheat Sheet, OWASP Cheat Sheet Series.
• Strict-Transport-Security header, MDN Web Docs.
• Content-Security-Policy header, MDN Web Docs.
• X-Content-Type-Options header, MDN Web Docs.
• Referrer-Policy header, MDN Web Docs.
• Permissions-Policy header, MDN Web Docs.
• Set-Cookie header, MDN Web Docs.
• Cache-Control header, MDN Web Docs.
• Access-Control-Allow-Origin header, MDN Web Docs.
• How to show HTTP response headers with cURL, simplified.guide.
• How to add custom response headers in Nginx, simplified.guide.
• How to configure CORS headers in Apache, simplified.guide.
• How to prevent clickjacking in Apache, simplified.guide.