Security headers: review CSP, HSTS and browser policies

Interpret missing security headers in context, inspect policy values, and plan safe follow-up checks instead of treating a score as a security audit.

Web & TLS

Open Security Headers →

Inspect the response your users receive

Run Security Headers against the public website hostname and review the returned response. A reverse proxy or CDN may add or remove headers after the application generates them. Results can also differ between a redirect, an error page and the final document. Record the target, status and IP version so a later retest can be compared meaningfully.

Understand the purpose of each policy

Content-Security-Policy can restrict which sources and browser capabilities a page uses. Strict-Transport-Security tells supporting browsers to use HTTPS for a host after receiving a valid policy over HTTPS. X-Content-Type-Options: nosniff restricts certain MIME-type guessing behavior. Referrer-Policy controls referrer information. These headers have different jobs; adding any arbitrary value does not make their protections equivalent.

Review values before deploying changes

A CSP must match the application’s required scripts, connections and other resources. On a diagnostics site this can include maps and verification widgets. Inventory dependencies and test an appropriate report-only policy before enforcement where supported. Plan HSTS only after validating HTTPS for the intended scope, especially before adding includeSubDomains. Do not copy a restrictive policy into production without checking the pages and services it affects.

Use the score to prioritize, not certify

A missing-header finding is a prompt to investigate. The tool does not inspect every page, authenticated flow or application vulnerability, and a present header may be weak or misplaced. Use HTTP Headers to see exact values and SSL Certificate to check the HTTPS endpoint. After a controlled deployment, retest both normal responses and representative error or redirect responses in a browser.

Worked example

Illustrative example — not a live test
Content-Security-Policy: missing
HTTP status: 200
Next step: inventory page dependencies, design a policy, test before enforcing.

What to check next

  1. Confirm the checked hostname and response status.
  2. Review missing headers and existing policy values individually.
  3. Test any policy change with the application’s real browser workflows.

Common questions

Does a perfect header score prove a site is secure?

No. Response headers are one layer of protection, and policy values still need review.

Should I add includeSubDomains immediately?

First verify HTTPS support across the subdomains that will be covered. HSTS scope and duration need a deployment plan.

References

HTTP security header guidance: OWASP

Content Security Policy: MDN