Tools
Security Headers Checker
Reads a site's response headers and reports which protective headers are present, missing or weakened, with the reason each one matters.
Published 26 Jul 2026 · Updated 24 Aug 2026 · 2 min read
Short answer
The Security Headers Checker requests a URL, reads its HTTP response headers, and reports which protective headers are present, missing or weakened — including Content-Security-Policy directives that undermine the policy they belong to.
Which headers are reported?
- Content-Security-Policy, including a directive-level review.
- Strict-Transport-Security, with max-age and subdomain scope.
- X-Content-Type-Options, Referrer-Policy, Permissions-Policy.
- X-Frame-Options, where CSP frame-ancestors is absent.
What the result does not tell you
Headers are browser-side instructions. They cannot detect injected server-side content, stolen credentials or a backdoor. Pair the header result with a search-side spam check and a file integrity review before concluding a site is healthy.
Who should use this checker?
- Developers about to ship a Content Security Policy and wanting to see the current baseline first.
- Site owners completing a security questionnaire or audit that asks which browser-side controls are in place.
- Teams that moved behind a CDN or reverse proxy and need to confirm headers still arrive intact.
- Anyone hardening a site after a compromise, where limiting the impact of a future injection is the goal.
What does each header actually protect against?
| Header | Risk it reduces | Practical starting value |
|---|---|---|
| Content-Security-Policy | Injected or third-party scripts executing and exfiltrating data | Report-only first, nonce-based script-src, then enforce |
| Strict-Transport-Security | TLS stripping and interception of the first cleartext request | max-age=31536000 once every subdomain serves valid HTTPS |
| X-Content-Type-Options | MIME sniffing turning an upload into executable script | nosniff |
| Referrer-Policy | Leaking full URLs, including tokens, to third parties | strict-origin-when-cross-origin |
| Permissions-Policy | Unwanted access to camera, microphone or geolocation by embedded content | Deny the features the site does not use |
| CSP frame-ancestors | Clickjacking and UI redress | 'none' unless the page is deliberately embedded |
How do you roll out headers without breaking the site?
STEP 01
Measure the baseline
Check a content page, an API response and an error page — headers are often set on only one of the three.
STEP 02
Start with the zero-risk headers
nosniff and Referrer-Policy can be deployed immediately with essentially no compatibility cost.
STEP 03
Run CSP in report-only mode
Collect violations from real traffic for a week, then remove genuine gaps from the policy rather than guessing.
STEP 04
Replace inline scripts with nonces
Keeping 'unsafe-inline' in script-src leaves the main attack path open, so treat it as a temporary measure with an owner and a date.
STEP 05
Raise HSTS max-age last
Verify every subdomain first; a long max-age with includeSubDomains is difficult to reverse quickly.
STEP 06
Re-check after every infrastructure change
A new CDN, WAF or platform migration can silently strip or override headers.
Sources
- HTTP headers reference — MDN Web Docs
Prefer summary updates? Subscribe to the newsletter.