Check Security Headers
Audit the headers your server actually sends so you can spot missing browser protections before a security review, CDN change, or deployment strips them out.
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
A secure website requires more than just an SSL certificate. The way your server communicates its security policies to the user's browser is dictated by HTTP response headers.
To check security headers is to verify that you are utilizing these built-in browser defense mechanisms. They form an invisible shield that protects the client from data theft and code injection.
Why it matters
Compliance frameworks and security audits almost universally require the implementation of robust security headers. Failing to configure them is considered a low-hanging fruit vulnerability by attackers and automated scanning bots. 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
This diagnostic tool queries the target server and analyzes the raw HTTP response. It scores the presence and validity of headers that mitigate XSS, enforce HTTPS, and restrict cross-domain data leakage.
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 Check Guides
Frequently Asked Questions
Which security headers should I check first?+
Is HTTPS enough without security headers?+
When do security headers usually break?+
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 →