Headers
A reference for HTTP headers, plus an audit that tells you which security headers a response is missing.
- badContent-Security-Policy
script-src allows 'unsafe-inline', so an injected <script> block or onclick= attribute executes. That is the one thing a CSP exists to stop — move to a nonce or a hash.
- badAccess-Control-Allow-Origin
* together with Access-Control-Allow-Credentials: true is rejected by every browser — the credentialed request fails outright. Echo the one allowed origin instead and add Vary: Origin.
- warnStrict-Transport-Security
Not set. A browser that has never seen this site will still try http:// first, and anything on the path can keep it there. Add max-age=63072000; includeSubDomains once every subdomain is on HTTPS.
- warnContent-Security-Policy
No base-uri. It does not fall back to default-src, so an injected <base> tag can still repoint every relative script URL on the page. base-uri 'none' or 'self'.
- warnX-Content-Type-Options
Missing. Without nosniff a browser may ignore your Content-Type and decide from the bytes what a response is — the step that turns an uploaded file into executable script.
- warnX-Frame-Options
Nothing controls framing: no X-Frame-Options and no CSP frame-ancestors, so any site can load this page in an iframe and overlay it. frame-ancestors 'self' (or 'none') fixes it.
- warnReferrer-Policy
Not set. Current Chrome, Firefox and Safari default to strict-origin-when-cross-origin so the exposure is small, but older browsers send the full URL — path, query and any token in it — to every site you link to.
- warnCross-Origin-Opener-Policy
Not set on an HTML document. same-origin cuts the window.opener link a cross-origin popup can otherwise use to navigate this page, and it is the first half of cross-origin isolation.
- warnServer
"nginx/1.18.0 (Ubuntu)" gives an exact version, which is all it takes to look up the CVEs that apply to it. Trim it to the product name or drop the header.
- warnX-Powered-By
"Express". Names your framework and often its version, for free, and nothing on the client reads it. Every stack has a one-line switch to turn it off.
- warnSet-Cookie sid
No Secure attribute, so the cookie also travels over plain HTTP. One downgraded request — an image, a stray link — is enough to leak it.
- warnSet-Cookie sid
No HttpOnly, so page JavaScript can read it. Deliberate for a value the front end needs; a problem for anything that identifies a session.
- warnCache-Control
This response sets a cookie and is also storable by a shared cache. Most CDNs refuse to cache a Set-Cookie response anyway, but where one does not, the next visitor is handed somebody else's cookie. Say private or no-store.
- warnContent-Type
text/html with no charset. The browser falls back to guessing the encoding, and encoding confusion has been a working XSS technique for years. Say charset=utf-8.
Paste what curl -sSI https://… prints, or copy the response headers out of the network tab. Nothing is uploaded — the parsing happens in this tab. A bad finding is broken or dangerous; a warn is a gap or a trade-off you may have made on purpose.
Security headers are a small, high-value checklist that is easy to leave half-finished. Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options and Referrer-Policy each close off a category of problem, and a site usually has some of them rather than all.
Paste a set of response headers and it tells you what is present, what is missing and what each one does. The reference half covers request and response headers generally, including the caching directives that are routinely set to something that does not mean what the author expected.
What people open it for
- Auditing a response for missing security headers
- Getting Cache-Control right for HTML against hashed assets
- Looking up what a header does before copying it from a config
In the terminal
tools headers
Every utility is also a command in the desktop's shell.