HTTP Security Headers Checker

HTTP security headers are small response fields that tell browsers how to handle transport, script execution, framing, referrer detail, browser features, cookies, caching, and cross-origin access. They do not repair vulnerable application code, but they can reduce the damage from common web mistakes and make deployment intent visible during review.

A header review is most useful before a release, after a proxy or CDN change, during incident cleanup, or when comparing a production response against a hardening baseline. The same response can look acceptable for a public static asset and risky for a sensitive account page, so the response type and the route being checked matter as much as the header names themselves.

Presence alone is a weak measure. A site can send Content-Security-Policy while still allowing wildcard scripts, send Referrer-Policy while choosing a value that leaks full URLs, or set cookies without the attributes that protect session handling. Good review reads both the header names and the values.

A strong header result should still be treated as evidence for one captured response, not as proof that every endpoint, redirect, error page, subdomain, browser path, and cache rule is correct. Repeat checks across the responses users actually receive before calling a header baseline complete.

Technical Details:

Security headers work through browser enforcement rules. HSTS affects future transport choices after a browser receives it over HTTPS. CSP restricts resource loading and framing. MIME sniffing protection asks the browser to trust the declared content type. Cookie attributes change how session cookies are sent or exposed. CORS and cross-origin isolation headers influence what other origins can read, embed, or share with the current response.

The safest review starts with the actual delivered response. Proxies, application servers, frameworks, CDNs, and redirect rules can all add, remove, merge, or override headers. Duplicate header fields also matter because browsers and intermediaries may combine or interpret repeated fields differently, while Set-Cookie is intentionally allowed to appear more than once.

Rule Core

The checker parses one pasted response into header fields, skips status lines, joins folded continuation lines, preserves duplicate Set-Cookie fields, and reports malformed lines that could not be read as name: value headers. The selected response profile changes how strict several findings are because a browser document, sensitive application page, API response, and static asset do not carry the same browser risk.

Score and Grade Logic

Each checked control produces Pass, Warn, Fail, or Info. Failures subtract the full priority weight from the score, warnings subtract 45% of that weight, and passing controls can add small bonuses for HSTS preload, combined cross-origin isolation signals, and CSP reporting.

Boundary behavior is intentionally conservative for browser documents and sensitive pages. A JSON or static asset response can receive informational findings for controls that would fail on a rendered document, while a sensitive app page raises cache, cookie, and isolation concerns more aggressively.

Everyday Use & Decision Guide:

Start with one response capture for one target. Put the host, route, release, or redirect hop in Target label, choose the matching Response profile, and set Observed response before reading the score. A final HTTPS document should be judged differently from a redirect hop or a cacheable static file.

Paste the full response header block into Response headers, including the optional HTTP status line when you have it. Use Hardened sample and Weak sample only as reference shapes. For real review, copied browser DevTools headers, curl -I output, proxy traces, and small text header captures are better evidence.

• Use Browser document for HTML pages where CSP, framing, feature policy, and referrer behavior matter directly.
• Use Sensitive app page for account, admin, billing, or personal-data pages where cache and isolation findings should carry more weight.
• Use JSON or API response when reviewing API headers, but still check MIME sniffing, CORS, cache, and accidental browser-rendered errors.
• Use Static asset response for scripts, styles, images, and other cacheable assets where missing document-only controls may be informational.
• Use Plain HTTP response or Redirect hop when the captured headers are not from the final HTTPS page; HSTS findings change for those cases.

Read Header parsing notes before the grade. A duplicate non-cookie header, folded line, or malformed line can change what the browser actually sees. Then read Header Scorecard for the full control list and Remediation Queue for the rows that need action.

Do not treat a high grade as approval by itself. A response can score well while another route lacks the same headers, a CDN variant strips a field, or an error page returns a different cache policy. Use Header Inventory to confirm parsed values and the Header Posture Map to see which categories retained score before writing a release note.

Step-by-Step Guide:

Review one captured response at a time so the grade, remediation rows, inventory, and posture map all describe the same browser decision.

1. Enter Target label with a short name such as portal.example.com production or /login redirect hop. The summary line should now name the response you are reviewing.
2. Choose Response profile. Start with Browser document for HTML, switch to Sensitive app page for account pages, or choose the API/static profile when the response is not meant to render as a document.
3. Set Observed response to Final HTTPS response, Plain HTTP response, or Redirect hop. If this is wrong, HSTS evidence will point at the wrong risk.
4. Paste raw headers into Response headers, drop a small header capture onto the field, or use Browse TXT for a text capture under 1 MiB. The status line may be present, but response-body text should be removed.
5. Check the source hint below the textarea. It should show the number of parsed header names. If Header parsing notes says lines were ignored, fix missing colons, accidental body text, or broken wrapped lines before relying on the score.
6. Read the top summary. Score, Pass, Warn, Fail, and Headers give a fast posture brief, but failing controls should override comfort from a good-looking grade.
7. Open Header Scorecard and confirm each Observed value matches the response you intended to test. Use the Evidence and Recommended action columns as the technical review notes.
8. Open Remediation Queue and clear Fail rows before Warn rows. If the queue is empty, open Header Inventory to make sure the parser found the expected HSTS, CSP, cookie, cache, CORS, and disclosure headers.
9. Open Header Posture Map when you need a category view. A low Transport, Injection, Session, Caching, or CORS bar tells you which part of the header baseline lost the most score.

Interpreting Results:

The first failing row matters more than the letter grade. A missing final-HTTPS HSTS header, report-only CSP on a browser document, missing framing protection, session cookie without Secure, or wildcard CORS with credentials needs attention even if other controls pass.

A clean result does not mean the application is secure. It means the pasted response avoided the checked header problems under the selected profile. Header review should sit beside CSP report sampling, browser testing, cookie-path review, CDN rule review, and application security testing.

When results conflict with a scanner or browser warning, compare the exact response first. Different tools may follow redirects, choose a different path, or inspect a cached variant. The Header Inventory table is the easiest place to confirm what was actually parsed.

Worked Examples:

Hardened production document

A final HTTPS browser document includes one-year-plus HSTS with includeSubDomains and preload, an enforced CSP with default-src 'self', nonce-based script authorization, object-src 'none', base-uri 'none', frame-ancestors 'none', X-Content-Type-Options: nosniff, a strict referrer policy, denied powerful features, no-store caching, a protected session cookie, and CSP reporting endpoints. The summary can show A+, Score 104/105, Pass 12, Warn 0, and Fail 0. The next check is route coverage, not more header name hunting.

Sensitive page with a weak legacy response

A sensitive app page has no HSTS, a report-only CSP with wildcard script sources plus unsafe script tokens, X-Content-Type-Options: sniff, Referrer-Policy: unsafe-url, missing framing protection, a session cookie without Secure or HttpOnly, no cache policy, detailed technology disclosure, and Access-Control-Allow-Origin: * with credentials. The summary can fall to F, Score 0/105, with multiple Fail and Warn rows. The Remediation Queue should drive the fix order because several findings are independent.

API response with intentional wildcard CORS

A public JSON response uses Access-Control-Allow-Origin: * and Cache-Control: no-cache with no cookies. Under JSON or API response, wildcard CORS can pass when credentials are not present, but missing HSTS, missing nosniff, missing explicit referrer policy, and missing CSP still affect the score. A result such as E with Fail rows is a reminder to review transport and MIME behavior even when the endpoint is meant to be read cross-origin.

Troubleshooting a messy paste

A copied terminal capture includes response headers, blank lines, and a few response-body lines without colons. The parser ignores the non-header lines and shows Header parsing notes. Clean the input to one response header block, keep repeated Set-Cookie lines intact, and rerun. If the Headers count changes, reread Header Scorecard before editing server rules.

Responsible Use Note:

Header findings can affect release decisions, but they are not a complete security assessment. Use the result as one review artifact, then confirm live browser behavior, server configuration, route coverage, CDN variants, cookie scope, and application vulnerabilities separately.

Pasted headers are parsed in the browser for this check. The page does not submit the header text to a server for analysis unless you separately share, copy, or upload that evidence somewhere else.

FAQ:

Glossary:

HSTS

HTTP Strict Transport Security, a response header that tells browsers to use HTTPS for future visits to a host.

CSP

Content Security Policy, a browser policy that restricts allowed resources, script behavior, framing, and reporting.

CORS

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

COOP, COEP, and CORP

Cross-origin isolation headers that influence opener relationships, embedded resource loading, and whether resources can be loaded cross-origin.

MIME sniffing

Browser behavior that guesses a response type from content; nosniff asks the browser to respect the declared type.

Report-only CSP

A CSP delivery mode that collects violation reports without blocking the browser action that caused the violation.

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.
• Secure cookie configuration, MDN Web Docs, February 11, 2026.
• Cross-Origin-Embedder-Policy header, MDN Web Docs.
• Cross-Origin-Resource-Policy header, MDN Web Docs.