Response policies shape what the browser may do
HTTP security headers tell a browser how to handle a response and some of the actions it might initiate. They can require future HTTPS connections, restrict resource loading, limit framing, prevent MIME sniffing and reduce referrer information. These policies are useful defences, but they do not repair every application vulnerability or prove that a website is secure.
This tool requests a public URL from the site server, follows a limited number of redirects and inspects selected headers on the final response. It shows the final URL and response status so that the observed policy can be connected to the page actually returned. The request does not execute JavaScript, log in or reproduce every header a particular user’s browser might receive.
Inspect the response that matters to the user
Begin with the complete URL of the page you intend to evaluate. A homepage, login page, API response and static asset can return different policies. Testing one path does not establish that the same headers are present everywhere. If a redirect changes the hostname or path, inspect the recorded chain and final destination before discussing the result.
Servers can vary responses by user agent, authentication state, cookies, geography, cache or content negotiation. This tool uses an ordinary diagnostic request from its own server without your account cookies. A logged-in browser might therefore see another page or another set of headers. For user-specific behaviour, compare the Network panel of the affected browser.
The checker limits redirects and blocks private destinations. A loop or redirect to an unsupported destination is reported as a failed check, not as a clean header report. The implementation reads response headers and does not need to download or render the full page body. It is a focused policy observation rather than a crawl of the entire site.
The Overview tab explains the findings. Measured data lets you search individual fields and values, while JSON report shows the complete export. Export JSON to retain a baseline, or print the findings for your own records. Review the report before sharing it: browser characteristics, token claims, and file names can reveal information about your setup.
Understand the policies independently
Strict-Transport-Security, usually called HSTS, instructs a browser to require HTTPS for future requests to the covered host during its lifetime. A positive max-age matters. An HTTP response cannot reliably establish HSTS in the same way as a valid HTTPS response, and including subdomains requires confidence that those hosts support HTTPS. Preloading is a separate deployment decision with long-lived consequences.
Content-Security-Policy restricts resource sources and other browser behaviour. Presence alone is not enough: a highly permissive script policy may provide little protection. Use the CSP auditor to inspect the value. A report-only policy records violations but does not enforce blocking. Frame restrictions can be expressed with CSP frame-ancestors and, for older support patterns, X-Frame-Options.
X-Content-Type-Options is normally set to nosniff. Referrer-Policy controls how much referrer information is shared in subsequent requests. Other headers, including Permissions-Policy and cross-origin isolation policies, have application-specific trade-offs. They should be chosen to match the site’s functionality rather than added blindly to accumulate a higher-looking score.
Turn missing headers into tested changes
A missing header identifies a question to investigate, not an automatic exploitable vulnerability. For example, an intentionally public image service may have different policy needs from a sensitive account dashboard. Understand the resource type, authentication model and embedding requirements before choosing a policy.
Deploy complex CSP changes with representative testing and, where appropriate, a report-only phase. A policy that blocks required scripts can break checkout or login. Framing restrictions can affect legitimate integrations. HSTS includeSubDomains can affect services operated elsewhere under the same domain. Coordinate changes with the people responsible for those services.
After deploying a change, inspect the response again and test the actual browser workflow. Caches, reverse proxies and application middleware can each add or remove headers. Keep an exported report with the response URL and timestamp so you can distinguish an old cached observation from the current configuration. A header audit should support a fix-and-verify process, not become a substitute for exercising the application.
A finding that HSTS is present should be assessed on an HTTPS response. Browsers do not establish an HSTS policy from an ordinary insecure response. Similarly, a security policy on a redirect is not necessarily the policy governing the final document; retain both the transport context and destination in your review.
Header checks in this implementation
| Header | Review focus |
|---|---|
| Strict-Transport-Security | Presence and a positive max-age; transport context still matters. |
| Content-Security-Policy | Presence; inspect directive quality separately. |
| X-Content-Type-Options | Presence and the expected nosniff value. |
| Framing restrictions | X-Frame-Options or CSP frame-ancestors in the observed response. |
| Referrer-Policy | Presence and the policy value for further review. |
Strengths and limitations
What this is useful for
The tool makes response status, redirects and selected policies visible without a browser extension. It gives administrators concrete configuration evidence and supports exporting results for deployment reviews. Findings explain the purpose of each missing control rather than reducing the response to an unexplained grade.
What to keep in mind
It inspects one unauthenticated response from a server-side perspective. It does not execute the page, test exploitability, validate every directive or inspect the whole application. A present header can still be ineffective, and a missing optional policy is not always a defect for that resource.
Common questions
Why are headers present in DevTools but missing here?
Your browser may be logged in, routed to a different edge or receiving a response varied by cookies and user agent. A service worker can also affect a browser workflow. Compare the exact final URL, status and response context rather than assuming both requests are equivalent.
Should I add every possible security header?
No. Choose controls that match the application and test their effects. Obsolete headers can be unhelpful, and restrictive policies can break legitimate functionality. Understand modern browser behaviour and the relevant resource type before adding configuration solely to satisfy a checklist.
Does the tool receive my login cookies?
No browser session cookies for the destination are forwarded. The entered public URL is sent to this server, which makes its own request. Avoid including secrets in URL query parameters, because those parameters become part of the requested destination and can be logged by infrastructure.
Does the report include Set-Cookie values?
The server returns a selected set of policy headers and excludes raw Set-Cookie values to avoid exposing unnecessary session data. To review cookie attributes, use the separate cookie auditor with redacted Set-Cookie lines from the response you are investigating.