What this tool checks
HTTP response headers are instructions your server sends to every browser that visits your site, before a single byte of the page renders. Some of them exist purely to tell the browser how to protect the visitor: don't run inline scripts unless explicitly allowed, don't let this page be embedded on another site, don't guess a file's type from its contents. Skip them — or forget about them — and you're relying entirely on your application code to cover every edge case, which it won't.
This analyzer requests your page the same way a browser would, reads the six headers that matter most for everyday web security, and grades what it finds: Content-Security-Policy, Strict-Transport-Security, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, and Permissions-Policy. Each one gets a plain-English explanation of what it actually does, plus a concrete value to copy if it's missing or too weak — not just a red X.
Why this matters more than it looks
Security headers are cheap to add (usually a single line in your web server or CMS config) and they close off entire categories of attacks instead of patching one bug at a time. Content-Security-Policy is the clearest example: even if an attacker manages to inject a <script> tag through a comment field or an unfiltered parameter, a properly configured CSP stops the browser from ever running it. Without that header, a single injection point turns into full account takeover.
Strict-Transport-Security (HSTS) solves a different problem. Without it, a visitor's very first request to example.com — before any redirect to HTTPS even fires — can be intercepted on public Wi-Fi and silently downgraded to plain HTTP. HSTS tells the browser to never attempt an insecure connection to that domain again, closing that window completely — but only after the header has been seen at least once, which is why preload exists for sites that want protection from the very first visit.
Common mistakes this tool catches
CSP with unsafe-inline. Teams often add this to unblock an inline <script> tag from an analytics snippet or a WordPress plugin, without realizing it reopens exactly the injection path CSP is meant to close. The analyzer flags this as a warning rather than a pass, because it meaningfully weakens the header even though it's technically present.
HSTS without includeSubDomains. A forgotten marketing subdomain or staging server still serving plain HTTP can still be used to attack visitors of the main site if HSTS doesn't cover subdomains — a gap that stays invisible until someone specifically tests for it.
X-Frame-Options missing entirely. This is the header that stops your login page from being loaded inside an invisible <iframe> on an attacker's site for clickjacking purposes. It's one line, and there's rarely a legitimate reason to skip it, yet it's one of the most commonly missing headers on small and mid-sized sites.
A concrete example
A typical WordPress site with a caching plugin and a CDN in front of it usually ships X-Content-Type-Options and a basic Referrer-Policy (set by the CDN's defaults) but nothing else — which usually lands around a C. Adding CSP and HSTS at the server or CDN config level, without touching a single line of PHP, is usually enough to reach an A. The per-header breakdown under your scan results is there specifically to show you which one to add first, not just that "something" is wrong.