Free tool Runs in your browser
A handful of headers stand between you and a bad day.
Paste the response headers from any site and see what they protect, what they give away, and exactly which lines to add. Cookies, CORS, HSTS, caching and the policy itself, all read in one pass.
The headers are read in this page. Your site is never contacted by us, and nothing you paste is uploaded or stored, so this works on staging and on anything behind a login.
Read a response
Response headers
Compare with an earlier response
Rolling security headers out is a sequence of small config edits. This says what each one actually changed, including anything it broke.
How to get them
- Terminal:
curl -sSIL https://example.com, which follows redirects and prints every response. - Chrome or Edge: F12, Network, reload, click the first request, then Response Headers, Raw.
- Firefox: F12, Network, reload, click the document request, Headers, then Raw.
- Behind a login: copy them from devtools on the page that matters. The response that sets your session cookie is the interesting one.
Set-Cookie lines are often stripped by copy tools. If you want the cookie flags checked, make sure they came across.
The reading
Headers to add
Your policy
Not sure where to find it? Open your site, press F12, and look at the response headers for the page, or run curl -sI https://example.com.
The reading
What does your site need?
Your policy
Set it on your server
Roll it out in Content-Security-Policy-Report-Only first, watch the reports, then switch to the enforcing header.
Your page source
The page is read in your browser. Nothing is uploaded, which matters because page source often carries keys and internal URLs.
What this page needs
Violation reports
Both shapes are understood: the old csp-report body and the Reporting API csp-violation body. Reports are read in your browser, which matters because they carry the URLs of pages your visitors were on.
The certificate
Where to get one
- From a live site:
openssl s_client -connect example.com:443 -servername example.com </dev/null | openssl x509 - From a browser: click the padlock, view the certificate, then export or copy the PEM.
- From a file: a .crt, .cer or .pem file is usually this text already. A .p12 or .pfx is a bundle with the private key in it, which is not what you want here.
Paste only the certificate. If the block says PRIVATE KEY, close the file.
What this is judging
Headers are cheap. Breaches are not.
The ones that stop an attack
A content policy turns many injection bugs into a blocked request. HSTS removes the plain-text first request an attacker on the network needs. Frame controls end clickjacking. These are configuration, not code.
The cookie flags
Secure keeps a session off the wire in plain text, HttpOnly keeps it away from injected script, SameSite blunts cross-site requests. Every cookie in your paste is listed with what it actually sets.
What the server volunteers
Exact versions in Server and X-Powered-By tell anyone scanning which published vulnerability to try first. Removing them is free and buys you a little quiet.
The ones that misfire
CORS with a wildcard and credentials, a response that sets a cookie and is cacheable by a proxy, a redirect to plain http. These are the mistakes that look like configuration and behave like a vulnerability.
Headers are the first ten minutes.
They do not fix broken access control, an exposed admin path, or logic that trusts the client. That takes someone testing the application by hand.
More free tools
- checkYourDomainSecSee what the internet already knows about your domain.
- Phishing & email analyzerRead a suspicious email: auth, links and indicators.
- Layered decoderTake base64, hex and gzip wrapping off a payload.
- Static file analysisRead a file's format, hashes, PE internals and hidden content, all in your browser.