Security Headers Checker
Use this variant when you want a more scanner-style view of the raw HTTP response and the individual header protections it exposes or misses.
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.
Need the full topic map first? Visit the Security Headers Guide for the related guides, tools, and supporting checks.
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 this means
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.
Why it matters
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.
Internal links for this topic
Use the hub page for the full topic map, then jump into the most relevant tools, guides, and related checks from the same cluster.
Cluster hub
Related checks
Related Check Guides
Frequently Asked Questions
What makes this page different from a general security headers check?+
Can static sites use security headers too?+
Which header is most likely to break production if rolled out badly?+
Scan your website now
Scan your website now
Run the dedicated tool for this issue to validate the live website quickly, then use the full SitePrivacyScore audit when you need a broader privacy review.
For deeper runtime checks, run the full privacy audit →