What security headers are

Security headers are HTTP response headers that harden browser behavior (CSP, HSTS, clickjacking protection, referrer leakage). This page shows a demo report with example recommendations.

Where it’s used

Security headers matter for public web apps: landing pages, dashboards, admin panels, SPAs, payment pages. In practice they’re often configured at the CDN/proxy layer (Cloudflare, nginx, ingress), so it’s easy to “lose” them during migrations and releases.

How teams usually verify headers

  • Smoke / security regression: a couple of key URLs + assertions for critical headers.
  • Environment diffs: dev/stage/prod often diverge.
  • After incidents: after CDN/proxy changes, quickly validate CSP/HSTS didn’t break.
More: definitions and how to test in a project

Definitions: HSTS, CSP, XFO and others

  • HSTS (Strict-Transport-Security) enforces HTTPS.
  • CSP (Content-Security-Policy) controls resource sources and is a major barrier against XSS.
  • XFO (X-Frame-Options) / frame-ancestors protects from clickjacking.
  • XCTO (X-Content-Type-Options: nosniff) prevents MIME sniffing.
  • Referrer-Policy reduces leakage of URLs/parameters via Referer.
  • Permissions-Policy restricts browser APIs.

How to use this in testing

  • Security regression: headers must not disappear after releases/CDN config changes.
  • Environments: dev/stage/prod often diverge — encode expectations in tests.
  • Real checks: assert headers in API tests or E2E (Playwright).

Next