Free tool
Security headers checker
Paste a raw HTTP response and get a pass/fail breakdown of the security headers that matter, with the exact header value that was checked.
Runs entirely in your browser
What this checks
- Strict-Transport-Security, including max-age length and includeSubDomains
- Content-Security-Policy, including unsafe-inline, unsafe-eval and wildcard sources
- X-Content-Type-Options and X-Frame-Options, including the dead ALLOW-FROM value
- Referrer-Policy, and how much referrer information it leaks
- Permissions-Policy, Cross-Origin-Opener-Policy, Resource-Policy and Embedder-Policy
- Server version disclosure and Cache-Control
Your data stays in this tab
This tool runs as JavaScript in your browser. Whatever you paste is read by the page and analysed locally — it is never uploaded, logged or stored, and the tool does not send any request to the API you are inspecting. Close the tab and it is gone.
What the checks mean
The baseline here is the set of response headers that the OWASP Secure Headers Project and MDN document, restricted to the ones that affect security rather than privacy or performance alone.
HSTS
Strict-Transport-Security tells the browser to stay on HTTPS for this host for a stated period. A max-age below one year is treated as a failure; the OWASP recommendation is two years (63072000). Add includeSubDomains only once every subdomain is HTTPS-only — it is not reversible for the length of themax-age, and a subdomain that cannot serve HTTPS will break for every user.
Content-Security-Policy
A CSP is the main defence against cross-site scripting, because it restricts where scripts may be loaded from rather than trying to filter dangerous input. The check looks for the three ways a policy is commonly neutered: 'unsafe-inline', 'unsafe-eval' and a bare * in script-src. It also checks forobject-src, base-uri andframe-ancestors, which are the directives most often left out. A Content-Security-Policy-Report-Only header reports violations without blocking anything, so it is reported separately and does not count as a policy being in place.
framing
X-Frame-Options: DENY andsameorigin are the two values browsers act on.ALLOW-FROM was removed from every browser that supported it and now does nothing, which is why it is reported as a failure rather than a warning.
Cross-origin headers
Cross-Origin-Opener-Policy, -Resource-Policy and-Embedder-Policy control how a page can be referenced, embedded and isolated from other origins. They matter most for applications that handle money or hold privileged sessions.Cross-Origin-Embedder-Policy: require-corp gives you cross-origin isolation, but it blocks third-party resources that do not send their own CORP headers, so it is worth checking your dependencies before enabling it.
A worked example
Paste this in and press Check headers:
HTTP/2 200 OK
Content-Type: application/json
Server: nginx/1.24.0
X-Powered-By: ExpressThe result is four failures — no HSTS, no CSP, noX-Content-Type-Options and no framing protection — plus a warning for the missing Referrer-Policy, and a note that the response advertises nginx/1.24.0 andX-Powered-By: Express. That is a realistic default Express response: nothing here is broken, but nothing here is protecting you either.
The same response with the headers added would pass every check:
HTTP/2 200 OK
Content-Type: application/json
Strict-Transport-Security: max-age=63072000; includeSubDomains
Content-Security-Policy: default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
Referrer-Policy: strict-origin-when-cross-originQuestions
How do I get the response headers to paste in?
In Chrome, Edge or Firefox, open the browser devtools (F12 on Windows, Cmd+Option+I on macOS), go to the Network tab, reload the page, click the request you care about, and open the Response Headers panel. Copy the whole block. The status line at the top is optional — the tool works with just the header lines.
Does it check cookies or the request headers?
No. It checks response headers only. Request headers come from the browser and are mostly out of your control, with the exception of things like Origin and Referer. Cookie flags are worth reviewing separately — the tool flags Set-Cookie presence information where relevant, but the definitive check for a cookie is its own attributes.
Why does it call a missing Strict-Transport-Security a failure but a missing Referrer-Policy only a warning?
The severity reflects how directly the header changes an attacker's options. Without HSTS, a browser has no instruction to stay on HTTPS, so a network attacker can downgrade a connection the user believes is secure. A missing Referrer-Policy leaks URL information in the Referer header, which is a privacy problem rather than a direct path to compromise. Both should be set; the ordering tells you where to start.
Is a passing result evidence that the site is secure?
No. These headers are a narrow slice of what makes a site secure. They say nothing about injection, authentication, authorisation, dependency vulnerabilities or the behaviour of the application itself. A clean result means the specific headers you checked are configured correctly.
Does the tool send my request to the site I am checking?
No. It reads only what you paste. It will not fetch a URL, resolve a host or make any outbound request of any kind. That is deliberate — a tool that fetched arbitrary URLs on your behalf would be scanning someone else's system.
Get EndpointCheck when it launches
We're building automated API security scanning for teams that ship REST APIs. It isn't live yet. Join the waitlist and we'll email you once when it is.