Security Headers Analyzer

Paste a set of HTTP response headers and get an instant, graded security review. The analyzer checks for the headers that matter — HSTS, Content-Security-Policy, X-Content-Type-Options, X-Frame-Options, Referrer-Policy and Permissions-Policy — explains what each one does and how to fix what's missing, then flags any headers that needlessly reveal your server software or framework version. Everything is evaluated in your browser; nothing is sent anywhere.

Tip: run curl -sI https://yoursite.com and paste the result.

How to use the Security Headers Analyzer

Fetch your site's response headers and paste them in. The quickest way is the command line — curl -sI https://yoursite.com prints the headers alone — but you can also copy them from your browser's DevTools Network tab (click the document request, then the Headers panel) or from any header-dumping tool. The analyzer parses the block, ignores the status line, and grades each security header as present and strong, present but weak, or missing.

The report opens with a letter grade and percentage based on the core OWASP-recommended header set, then lists every check with a plain-English note on what it found and what to change — for example, an HSTS header with a short max-age, or a Content-Security-Policy that still allows unsafe-inline. Below the table, an information-disclosure section flags headers like Server and X-Powered-By that reveal software and versions an attacker can fingerprint. Fix the missing and weak items in your server or CDN config, re-fetch, and paste again to confirm the grade improves.

What HTTP security headers do

HTTP security headers are response headers a server sends alongside a page that instruct the browser to enable protective behaviours. They're one of the cheapest, highest-leverage hardening steps available: each is a single line of server configuration, yet together they defend against whole classes of attack — cross-site scripting, clickjacking, protocol downgrade, MIME-type confusion and referrer leakage among them. Because they're enforced by the browser itself, they protect users even when a bug slips through elsewhere in the stack.

The headers do different jobs. Strict-Transport-Security (HSTS) forces every future request over HTTPS, closing the window for downgrade and cookie-hijacking attacks; a long max-age with includeSubDomains is the strong form. Content-Security-Policy (CSP) is the most powerful and the most involved — it whitelists where scripts, styles and other resources may load from, which is the single best mitigation against XSS, though policies that permit unsafe-inline or unsafe-eval give much of that protection back. X-Content-Type-Options: nosniff stops the browser from second-guessing declared content types, and X-Frame-Options (or CSP's frame-ancestors) prevents your pages being framed for clickjacking. Referrer-Policy controls how much of the URL leaks when users click outbound links, and Permissions-Policy switches off powerful features like camera and geolocation that the page doesn't use.

The flip side is information disclosure. Headers such as Server: nginx/1.25.3 or X-Powered-By: PHP/8.3.0 volunteer your exact software and version, which is precisely the reconnaissance an attacker wants when matching a target against a list of known vulnerabilities. They serve no purpose for visitors and are best removed or reduced to a generic value. Getting the security headers right and the disclosure headers gone is a quick win that measurably raises the cost of attacking your site — and this tool turns a pasted header block into a concrete checklist for doing exactly that.

Common use cases

  • Pre-launch hardening. Check a site's headers before it goes live and fix gaps in one pass.
  • Security audits. Produce a quick, readable grade for a client or internal review.
  • CI sanity check. Paste headers from a staging deploy to catch a CSP or HSTS regression.
  • Learning. See what each header does and why it matters, with concrete fix suggestions.

Frequently asked questions

Why do I paste headers instead of entering a URL?
Browsers block cross-origin requests that would let a page read another site's response headers, so a purely in-browser tool cannot reliably fetch them for you. Pasting the output of curl -I or your DevTools Network tab is accurate, works for any site including staging and intranet hosts, and keeps everything local — nothing you paste leaves your browser.

How is the grade calculated?
Each core header counts toward the score: present and strong is full marks, present but weak is half, and missing is zero. The percentage is the total over the maximum for the required header set, mapped to a letter grade from A+ to F. The two cross-origin isolation headers are treated as optional recommendations and don't penalise the core score.

What counts as a "weak" header?
A header that's present but not configured for full protection — for example an HSTS max-age under six months, a Content-Security-Policy that allows unsafe-inline or unsafe-eval, or an X-Content-Type-Options value that isn't exactly nosniff. The note next to each result explains what to change.

Why does it flag the Server and X-Powered-By headers?
Those headers reveal the exact software and version running your site, which helps attackers match you against known vulnerabilities. They provide no benefit to visitors. Removing them or replacing them with a generic value is a simple, recommended hardening step.

Does a perfect grade mean my site is secure?
No — it means your response headers follow current best practice, which is one important layer. Security headers don't replace input validation, authentication, dependency patching or the rest of a defence-in-depth approach. Treat the grade as a useful checkpoint, not a guarantee.