What URL checkers can see
A checker that fetches your homepage sees one unauthenticated response. It tells you whether a marketing page sets a Content Security Policy. Useful, but that page holds no customer data and sets no session cookie.
Live tool
HTTP response header analyzer for authenticated responses
Paste a full response header block and see what is wrong with the security headers. Works on responses behind a login, which URL based checkers cannot reach. Everything runs in your browser.
CSPCookie flagsCORSHSTSCacheInformation disclosure
Copy the whole response header block from Burp, your browser's network tab, or curl -sS -D- -o /dev/null. The request line and body are ignored.
Findings
Paste headers, or load an example, to see findings.
Nothing leaves this page. Parsing happens in your browser. No header, cookie or token is sent anywhere, logged or stored.
The difference
Why authenticated responses are the ones that matter
What they cannot see
The session cookie issued at login. The API response returning a customer record, which is where API security testing spends most of its time. The account page an intermediary might cache. Every one of those is behind authentication, so a URL based checker never reaches them, and every one of them is where the real finding lives.
Paste the response you actually care about and the analysis applies to that response, not to a public page that happens to share the domain.
Header by header
What each header actually protects against
Content-Security-Policy
Tells the browser which sources may supply scripts, styles and frames, so an injected script from an unexpected place is refused. It limits the damage of cross site scripting; it does not fix the injection, and a weak policy stops nothing.
Strict-Transport-Security
Tells the browser to use HTTPS for the host, and optionally its subdomains, for a set time. It stops a network attacker downgrading a later visit to plain HTTP. It cannot protect the very first visit unless the domain is preloaded.
Set-Cookie flags
HttpOnly, Secure and SameSite make a session harder to steal or ride, in the order set out below. None of them helps if the session value is predictable or never expires.
CORS headers
Access-Control-Allow-Origin and its companions tell the browser which other origins may read a response. They relax the same origin policy; they never add protection. The risk is an allowlist that is too wide, or an Origin reflected back unchecked, which lets any site read authenticated data.
Framing controls
X-Frame-Options and the CSP frame-ancestors directive decide whether other sites may embed the page. They stop clickjacking, where a real page is hidden under a decoy and the user is tricked into clicking. They do not stop the page being fetched or scraped directly.
Referrer-Policy
Controls how much of the current URL is sent to other sites in the Referer header. It stops identifiers, reset tokens and search terms in the path or query string leaking to third party scripts and outbound links.
Cache-Control
Tells browsers, proxies and CDNs whether a response may be stored, and for how long. It does not protect data in transit; on an authenticated response, it is what keeps one user's data from being served to another.
CSP
Content Security Policy, and why most of them do nothing
Many policies in production would not stop the attack they exist for. The usual reason is 'unsafe-inline' in script-src. Cross site scripting almost always arrives as an inline script or an inline event handler, and unsafe-inline permits exactly that, so the policy allows the attack it was written to block.
Wildcard and scheme sources are the second reason. A script-src of *, https: or a broad CDN domain lets an attacker load a payload from any host that matches, including shared CDNs that serve files anyone can publish.
The pattern that works
A nonce or hash based policy with strict-dynamic. The server adds a fresh random nonce to each response and to every script tag it trusts, strict-dynamic lets those scripts load their own dependencies, and everything else is refused. Add object-src 'none' and base-uri 'self' and the common bypasses are closed.
Why frame-ancestors belongs in the policy
frame-ancestors is the modern replacement for X-Frame-Options. It accepts a list of permitted parent origins instead of a single DENY or SAMEORIGIN. X-Frame-Options can stay for older clients, but should not be the only framing control.
Cookies
The cookie flags that matter, in order
- HttpOnly. Without it, one cross site scripting bug can read the session and send it away, which turns a script injection into account takeover. Double submit CSRF tokens are the exception, because the page has to read them.
- Secure. The cookie is only sent over HTTPS. Without it, a single request over plain HTTP carries the session in clear text.
- SameSite, and its three values. Strict never sends it on a cross site request, but users arriving from another site's link appear logged out. Lax sends it on top level navigation but not on cross site form posts or background requests, which blocks most CSRF. None sends it everywhere, requires Secure, and puts all of the CSRF defense back on tokens.
- Domain scope. A cookie with no Domain attribute goes only to the host that set it. Setting Domain to the parent sends it to every subdomain, so a takeover or bug on any one of them can read or overwrite the session.
- The __Host- prefix. A cookie named with __Host- must be Secure, use Path=/ and carry no Domain, and the browser enforces all three. It is the simplest way to guarantee a session cookie cannot be widened or planted by a subdomain.
Caching
Caching authenticated responses
This is the check URL based scanners cannot run, and it is the one that causes real cross tenant exposure. If a shared cache can store an authenticated response, the next request that matches the same cache key can be served the previous user's data. It is the same failure that access control testing looks for, arriving through infrastructure instead of code.
no-cache is not no-store
no-cache lets the response be stored, but requires the cache to revalidate with the server before reusing it. no-store forbids storing it at all. For responses carrying personal or tenant data, no-store removes the risk; no-cache relies on every cache in the path revalidating correctly.
Why public is a finding, not a nitpick
public explicitly allows shared caches such as CDNs and corporate proxies to keep the response, even when the request carried credentials. On a user specific response that is an instruction to hand one customer's data to whoever asks next, and the only thing preventing it is how the cache happens to be configured today.
private is the middle ground: the browser may keep the response, shared caches may not. Also check Vary. A CDN that builds its cache key without the Cookie or Authorization header is the configuration that turns a missing no-store into a leak.
FAQ
Common questions
Is it safe to paste real response headers here?
The parsing runs entirely in your browser. Nothing is transmitted, logged or stored, and you can confirm that by opening your network tab while you paste. That said, treat any session cookie you paste as exposed on your own screen, the same way you would treat a token pasted into the JWT inspector.
Where do I get the header block?
Burp, the network tab in your browser's developer tools, or curl with -D-. Copy everything from the status line down to the blank line before the body.
Does a missing security header count as a vulnerability?
On its own, rarely. A missing Content Security Policy is not an exploit, it is a missing mitigation. It matters when combined with something else: an XSS that a policy would have blocked, a session cookie without SameSite next to a state changing endpoint with no CSRF token. Severity comes from the combination, not the absent header, which is why a manual penetration test judges them together.
Why does it flag cache headers on an API response?
A response carrying one customer's data with no cache directive can be stored by a CDN, a corporate proxy or the browser itself, and then served to somebody else. It is one of the quieter ways cross tenant exposure happens, and it never shows up on a public page scan.
Can wildcard CORS with credentials actually work?
No, and that is the point. Browsers reject the combination, so developers often replace the wildcard with code that reflects whatever Origin arrived. That reflection is far more dangerous than the wildcard was, and this tool flags it.
Why does my site pass a header scanner but get flagged here?
A scanner fetches a public page, usually the best configured response you have. The login response that sets the session cookie, the API that returns customer records and the account pages often come from different code or a different server block, with different headers. Paste those and the results change.
Is X-XSS-Protection still worth setting?
No. The browser filter it controlled has been removed from current browsers. Leave it out or set it to 0, and put the effort into a Content Security Policy instead.