Analyze HTTP security headers and get a security score
Analyzing headers for ...
Security Score
Header Analysis
Header
Status
Value
Present
Invalid
Missing
Recommendations
•
Error
About Security Header Analyzer
Our free Security Header Analyzer scans HTTP response headers and provides a security score from 0 to 100. It checks for critical security headers like Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options, and more. Get actionable recommendations to harden your website's security.
How to Use
1Enter the website URL you want to analyze
2Click "Analyze Headers" to scan all HTTP response headers
3Review the security score and recommended header configurations
Use Cases
•Security Auditing: Quickly assess security header posture across your web properties
Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy and related headers, each assessed on whether it is present and whether it is set correctly. Presence alone is not the same as correctness: a Content-Security-Policy containing report-only changes nothing, and an X-Frame-Options value of ALLOWALL defeats the header's purpose entirely. The analysis evaluates the value, not just the header name, because a misconfigured header is more misleading than a missing one.
A score of 80-100 indicates a strong security posture with most critical headers properly configured. Scores 50-79 show room for improvement, while below 50 suggests significant security gaps that should be addressed promptly.
Security headers are configured at the web server level. For Nginx, add add_header directives in your server block. For Apache, use Header always set directives. For cloud platforms, check your CDN or load balancer settings. Our recommendations section provides specific guidance.
Because TLS protects the connection, not the page once it is rendered. Headers control what the browser will allow the page to do and how it treats content around it — framing, MIME sniffing, referrer leakage and content-type confusion. A page delivered over a perfect certificate can still be framed by an attacker to capture clicks, which is a risk TLS has no bearing on.
HSTS first, because it is the only one that closes the window before encryption is established and it covers the whole origin. Then the content-type and framing protections, which prevent content confusion and clickjacking respectively. The referrer and permissions policies matter more for privacy than for attack surface. When prioritising, do HSTS and the injection defences first and treat the rest as incremental.
It can be, if you deploy it carelessly. The header is honoured for its full duration with no client-side override, so a value of a year means a year of HTTPS-only browsing for that domain even if your certificate breaks. Start with a short max-age, confirm nothing under the domain still needs plain HTTP, then raise it gradually. Preload is effectively irreversible, so treat that step as permanent.
Yes, for the ones that matter. A security header present only on some responses is not a control — an attacker aims for whichever route lacks it, and error pages and API endpoints are the usual soft spots. Confirm coverage across your main pages, redirects, error responses and any other host serving the same content, since headers are per-response rather than per-origin.
Because the value can be wrong even when the header exists. Some headers take no value and only need to be present; others have a specific value that changes what they mean — a referrer policy of unsafe-url satisfies presence while leaking what the policy exists to withhold, and a framing header with a permissive value defeats the protection. That is why this page reports presence and validity as separate results.
How Headers Are Scored
Fetch the site and compare its response headers against a weighted set of expectations. Each header is checked for presence and, where an exact value matters, for correctness.
1Report presence and validity separately for each header. A missing header and a present-but-wrong one are different problems with different fixes, and a page that only says present or absent hides which you have.
2Apply weights, not equal counts. Headers differ in how much they protect: a clickjacking defence and a referrer policy are not worth the same as HSTS, so the score reflects relative value rather than a tally.
3Generate a specific recommendation per finding, naming the expected value where one applies. “Add X-Frame-Options header” is actionable; a bare missing-header count is not.
Headers only apply to the response actually fetched. A site can set them correctly on the page you checked and not on an API route, an error page or a different host, so coverage across responses is worth verifying separately.
Tips & Best Practices
•Enable all recommended security headers for maximum protection
•Test security headers after configuration changes
•Monitor header configuration for unauthorized modifications
•Use header analysis to verify security hardening effectiveness
