This security headers checker scans any website and shows which of the six most important HTTP security headers it actually sends, and which ones are missing. Enter a URL below and the check runs on our server, so there’s nothing to install and no browser limitation to work around. Whether you’re auditing your own site or checking one before trusting it, this gives you a clear, immediate answer.
What This Security Headers Checker Looks For
This tool checks for the six headers covered in the OWASP Secure Headers Project, the standard reference for HTTP security header best practices: Strict-Transport-Security, Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, and Permissions-Policy. Missing any of these doesn’t necessarily mean a site is broken, but each one closes off a specific, well-understood category of attack.
🔒 Checks are performed by our server. We do not store the URLs you check.
🔒 Strict-Transport-Security (HSTS)
Tells the browser to only ever connect over HTTPS for this site, even if someone types http:// or clicks an old link. Without it, a brief window exists where a downgrade attack could intercept the first request. This works alongside proper certificate handling, covered in our guide on dangerous SSL validation mistakes.
🛡️ Content-Security-Policy (CSP)
Tells the browser exactly which sources are allowed to load scripts, styles, and other resources on the page. A well-configured CSP is one of the strongest defenses against cross-site scripting, since even a successful injection has nowhere to load malicious code from.
🖼️ X-Frame-Options
Controls whether other sites can embed this page inside an iframe. Without it, an attacker can layer an invisible version of the page over their own content, tricking users into clicking something they never meant to, an attack known as clickjacking.
📄 X-Content-Type-Options
Set to nosniff, this stops the browser from guessing a file’s content type instead of trusting what the server declared. Without it, a file uploaded as an image could potentially be interpreted as something else entirely. Related: our breakdown of unrestricted file upload vulnerability covers a similar risk from the upload side.
🔗 Referrer-Policy
Controls how much of the current page’s URL gets sent along when a user clicks a link to another site. Without a strict policy, a URL containing something sensitive, like the tokens covered in password reset tokens in URLs, can leak to a completely unrelated third party the moment someone clicks away from the page.
⚙️ Permissions-Policy
Restricts which browser features, camera, microphone, geolocation, and others, a page and anything embedded in it are allowed to request. It’s a defense-in-depth layer: even if a script gets injected somehow, this limits what it can actually access.
None of these headers require rewriting your application. Most are a handful of lines in your server or CDN configuration, and once set, they apply to every request automatically. The gap is usually that nobody added them in the first place, not that they’re difficult to add.
Pair this with our JWT decoder if you’re also reviewing authentication tokens, or check the full list of free security tools for everything else in this set.