HTTP security headers
Check whether your website has the right HTTP security headers configured.
How the header check works
The tool sends a regular HTTPS GET request to the URL you enter and reads the response headers - the same headers every browser receives. Nothing is parsed from the page body; security headers live entirely in the HTTP response.
We then look for the headers that control browser-side protections: Strict-Transport-Security (HSTS), Content-Security-Policy (CSP), X-Frame-Options, X-Content-Type-Options and Referrer-Policy. Each present header adds to the score, and missing ones are listed with an explanation of the risk they leave open.
Because the check follows redirects, the result reflects the final URL. If your site redirects from HTTP to HTTPS or from the apex domain to www, the headers you see belong to the destination.
How to read the results
The score is a quick orientation, not a certification. What matters in practice:
- HSTS - tells browsers to always use HTTPS for your domain. A max-age of at least half a year is common practice; add includeSubDomains only if every subdomain serves HTTPS.
- CSP - the strongest defence against XSS, but also the hardest to write. Even a basic policy restricting script sources is a big improvement over none.
- X-Content-Type-Options: nosniff and X-Frame-Options (or the frame-ancestors CSP directive) - cheap one-line protections against MIME sniffing and clickjacking.
Common problems
Header configured, but reported as missing. A reverse proxy or CDN in front of your app may strip or override headers. Compare the response via curl -I directly against the origin and against the public URL to find which layer drops it.
CSP present, but ineffective. Content-Security-Policy-Report-Only logs violations without blocking anything. It is useful for testing, but offers no protection - switch to the enforcing header once your report log is clean.
Different routes return different headers. Headers set in application middleware may not apply to static files served directly by the web server, or to error pages. Test a static asset URL and a 404 page as well.
Frequently asked questions
Which security headers should every website have?
A reasonable baseline: Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options: nosniff, Referrer-Policy and frame protection via X-Frame-Options or CSP frame-ancestors. APIs additionally benefit from Cache-Control: no-store on sensitive responses.
Is the X-XSS-Protection header still needed?
No. Modern browsers removed the XSS auditor it controlled, and in old browsers the header could even introduce vulnerabilities. Use a strict Content-Security-Policy instead.
Does HSTS protect the very first visit?
Not by itself - the browser only learns the rule from the first HTTPS response. To cover the first visit, submit your domain to the HSTS preload list (hstspreload.org) and use the preload directive together with includeSubDomains.
Can a wrong header break my site?
Yes, two classic cases: an overly strict CSP blocks your own scripts or inline styles, and HSTS with includeSubDomains breaks any subdomain that still runs plain HTTP. Roll out CSP in report-only mode first and start HSTS with a short max-age.
Track header changes continuously
ePulz.io alerts you when a header changes (for example after a deployment that accidentally removed CSP).
Get started with ePulz.io →About this tool
Security headers tell the browser how to protect your visitors. This audit shows whether HSTS, Content-Security-Policy, X-Frame-Options, X-Content-Type-Options and Referrer-Policy are actually present and scores the result, so you can catch clickjacking and MIME-sniffing gaps after a deploy.