Security Headers Checker
Verify the presence and configuration of essential HTTP response headers. Defend your website against cross-site scripting (XSS), clickjacking, and more.
Use this guide to understand the issue, validate the problem manually, and run the live scanner when you are ready. Get results in under 30 seconds.
Run the scanner for this issue
The fastest way to confirm this issue on a live domain is to run the dedicated scanner. It checks the technical signal directly, then shows the finding in plain language with remediation context.
Why teams search for this check
Search intent around this topic usually comes from one of three pressures: a buyer or procurement questionnaire, a legal or compliance review, or an engineering team trying to validate a risky browser behavior before launch.
This page is written to answer that intent directly, without generic filler. It explains what the issue means technically, how to confirm it manually, and what a defensible fix looks like in production.
What are HTTP security headers?
When a web server responds to a browser's request, it includes HTTP response headers. These headers contain metadata about the response. Security headers specifically instruct the browser on how to behave securely when handling the site's content.
By setting strict security headers, you can prevent modern browsers from falling victim to common client-side vulnerabilities, effectively creating a powerful first line of defense with very little configuration effort.
Missing or misconfigured security headers leave your users vulnerable to attack. For instance, without X-Frame-Options, an attacker could embed your site in a malicious iframe to steal clicks (clickjacking). In practice, teams usually do not lose trust because of a single configuration detail. They lose trust when the issue suggests weak governance, undocumented vendors, avoidable data sharing, or a disconnect between legal claims and live technical behavior.
What this tool specifically detects
- Missing or weak HTTP response headers such as HSTS, CSP, X-Frame-Options, Referrer-Policy, and Permissions-Policy.
- Header gaps that increase the browser attack surface for XSS, clickjacking, MIME confusion, or URL leakage.
- Common hardening issues that are frequently called out in enterprise vendor reviews.
When this becomes critical
- You handle authentication, customer data, or enterprise procurement reviews.
- Your site relies on third-party scripts that broaden the browser attack surface.
- You need to demonstrate repeatable security hardening rather than ad hoc configuration.
How this check works
The tool makes a simple HTTP HEAD request to the target URL and parses the returned headers. It checks for the existence and correct formatting of crucial headers like Strict-Transport-Security, X-Frame-Options, and Content-Security-Policy.
The goal is not to create noise. The goal is to surface the signal that matters first, show you how the issue normally appears in production, and help you decide whether you need a quick fix, a deeper audit, or a broader policy update.
Real-world examples that trigger this finding
A login area is embedded inside a malicious iframe because X-Frame-Options was never configured.
A password reset URL leaks to a third-party domain because Referrer-Policy was omitted.
A site migrates to a new CDN and silently loses HSTS and CSP headers during the move.
How to manually detect this issue
- Run a HEAD request with curl and inspect the response headers for every public entry point.
- Check CDN, reverse proxy, framework, and web server configuration separately, because one layer can override another.
- Verify behavior after redirects so the final destination still carries the expected policy headers.
How to fix it
- Define a baseline header policy for all public responses and enforce it at the CDN or edge layer.
- Roll out CSP and Referrer-Policy carefully using report-only testing when needed.
- Add automated regression checks to deployment pipelines so headers do not disappear during infrastructure changes.
Common mistakes teams make
- Configuring headers only on the origin while the CDN strips them.
- Using a permissive CSP that creates a false sense of safety.
- Treating Permissions-Policy as optional even when third-party scripts are present.
Related Tools and Guides
Frequently Asked Questions
Which security headers are the most important?+
What is X-XSS-Protection?+
How do I add security headers to my website?+
What does X-Content-Type-Options: nosniff do?+
Will adding security headers break my site?+
Need a broader privacy review?
Run the full SitePrivacyScore audit when you need more than a single point-in-time check. It combines trackers, cookies, headers, consent signals, and remediation guidance in one report.
For deeper runtime checks, run the full privacy audit →