Security Header Analyzer
Analyze HTTP security headers
Security Header Analyzer tool
Security Header Analyzer: key facts
- What it does
- Analyze HTTP security headers
- Category
- Developer Tools
- Cost
- Free, with no account, sign-up, or install.
- Your data
- Runs entirely in your browser — the files and text you enter are never uploaded to a server.
- Last reviewed
- . Report an incorrect result.
Understanding the Security Header Analyzer
HTTP security headers are a frontline defense against attacks like cross-site scripting and clickjacking, yet they are easy to forget to configure. Security Header Analyzer reviews a set of response headers, checks for the ones that matter, rates how complete your coverage is, and explains what each missing header would protect against.
It is built for a security or deployment review: paste the response headers from a site and instantly see whether Content-Security-Policy, Strict-Transport-Security, and the rest are present, with a score that summarizes your posture. Developers use it to harden a site before launch; auditors use it to document gaps with concrete recommendations.
Note that it analyzes headers you paste in — it does not fetch a URL for you — so you control exactly which response is being assessed.
Getting a result
- Copy the response headers from your site (from your browser's network tab or a curl -I command).
- Paste them into the "HTTP Headers" box, one per line in Header-Name: value form.
- Click Analyze.
- Read the security score and the per-header results: which are present, their severity, and a recommendation for each, then Copy the summary.
Analysing headers you paste in
The tool reads a block of response headers, splitting each line at the first colon into a name and value, and checks them against the security-relevant headers it knows about. Because a browser cannot fetch arbitrary cross-origin responses and read their headers, this works on headers you supply rather than by requesting a site itself.
Getting them is straightforward: open the network panel in your browser's developer tools, select the main document request, and copy the response headers. A command-line request showing headers only works equally well, and is easier to script across several environments.
Reviewing them as a set rather than individually is the useful part, since several of these headers overlap and a couple are superseded by others — presence alone is a weaker signal than whether the collection is coherent.
- Strict-Transport-Security instructs browsers to use HTTPS for a stated period.
- X-Content-Type-Options with the nosniff value stops the browser second-guessing a declared content type.
- Content-Security-Policy is the most powerful and the most intricate of them.
Reasons to use it here
- It checks eight key security headers and assigns each a severity (from critical for Content-Security-Policy down to low), so you know which gaps to fix first.
- It produces a coverage score and a specific recommendation per header, turning a review into an actionable checklist.
- Because it analyzes headers you paste, you can assess any response — including staging environments or authenticated requests — that a URL-fetching scanner could not reach.
- Analysis is entirely client-side, so headers that may include sensitive values are never uploaded.
What each header actually buys you
Content-Security-Policy is the one that repays real effort, because it restricts where scripts, styles, images, and frames may load from and is consequently the strongest available mitigation against cross-site scripting. It is also the easiest to get wrong: a policy containing unsafe-inline for scripts gives away most of the protection, and a missing host silently breaks a third-party integration. Deploying in report-only mode first, and watching the reports, is the way to avoid breaking a site.
The others are narrower. Strict-Transport-Security prevents protocol downgrade after a first visit. Referrer-Policy controls how much URL detail leaks to other origins. Permissions-Policy disables device APIs a page has no business using. X-Frame-Options blocks framing and clickjacking, though the frame-ancestors directive in CSP supersedes it. X-Content-Type-Options prevents MIME sniffing. X-XSS-Protection is obsolete and best omitted entirely, since the browser filters it controlled have been removed.
Headers are a hardening layer, not a substitute for the fundamentals. They will not fix an injection vulnerability, a broken authorisation check, or an exposed credential — and they are worth checking after every deployment, since a change of CDN, proxy, or framework configuration can drop them without anyone noticing.
Frequently Asked Questions
Which security headers does it check?
It evaluates eight: Content-Security-Policy, Strict-Transport-Security, X-Frame-Options, X-Content-Type-Options, X-XSS-Protection, Referrer-Policy, Permissions-Policy, and Cache-Control — each tied to a specific protection such as preventing XSS, enforcing HTTPS, or blocking clickjacking.
Does this tool scan a website by URL?
No. It analyzes the headers you paste into it rather than fetching a site itself. That design lets you assess responses a public scanner cannot see — like internal environments or authenticated pages — but it means you need to supply the headers. To capture live headers from a URL, use an HTTP headers checker first.
How is the security score calculated?
The score reflects how many of the eight checked headers are present in what you pasted, expressed as a percentage. It is a quick coverage indicator; the per-header severity and recommendations tell you which missing headers carry the most risk.
Where do I find my site's response headers?
Open your browser's developer tools, go to the Network tab, reload the page, click the main document request, and read the Response Headers section. Alternatively, run curl -I https://yoursite.com from a terminal and copy the output.
