News
Security Headers Checklist for Public Websites
September 7, 2025
A security headers checklist for public websites is a browser-guardrail list, not a pentest. Ship Content-Security-Policy (start report-only if needed), Strict-Transport-Security with a long max-age, framing controls via CSP frame-ancestors plus X-Frame-Options, Referrer-Policy, X-Content-Type-Options=nosniff, and a tight Permissions-Policy. RoastMyOpsec's free audit reads those signals on the primary document response. Headers will not fix an exposed .env, but missing headers still make XSS, clickjacking, MIME confusion, and HTTPS downgrades easier.
The checklist
Apply these on HTML document responses. APIs may need a different subset. Confirm at the CDN so every marketing route inherits the policy.
- CSP: default deny with explicit script, style, image, connect, and frame-ancestors. Report-only until it stops breaking checkout widgets.
- HSTS: max-age you can live with; includeSubDomains only if every subdomain is ready.
- Framing: frame-ancestors 'none' (or 'self') and matching X-Frame-Options.
- Referrer-Policy: strict-origin-when-cross-origin is a sane default for most sites.
- X-Content-Type-Options: nosniff.
- Permissions-Policy: disable camera, microphone, geolocation, and payment unless the page needs them.
What changed in how teams ship this
Tag managers, chat widgets, and A/B tools are why CSP still dies in committee. The current pattern that works: lock framing, HSTS, nosniff, and referrer this week. Put CSP in report-only, collect violations, then enforce. Do not wait for a perfect nonce story before denying iframes.
Permissions-Policy is the quiet win. Marketing sites almost never need device APIs. Turning them off is a one-line edge rule.
Header vs exposure
Headers are guardrails. They are not a substitute for keeping .git, .env, and source maps off the origin. Run the path checks too.
| Control | Blocks or slows | Does not replace | Takeaway |
|---|---|---|---|
| CSP | Many XSS and unwanted script sources | Server-side auth bugs | Hard, high leverage |
| HSTS | Later HTTP first hops | Mixed content already in HTML | Pair with HTTPS redirects |
| Framing headers | Clickjacking | Open redirects | Cheap on brochure sites |
| nosniff | MIME confusion | Wrong Content-Type on APIs | Still ship correct types |
How RoastMyOpsec grades headers
One consented GET. No header injection. Findings map to the free 'browser guardrails missing in transit' pack when CSP, HSTS, framing, referrer, nosniff, or Permissions-Policy are weak or absent.
Paste a URL you own and treat the roast as a punch list for the edge config.
Common mistakes
The first mistake is setting headers only on / and not on /blog/*.
The second mistake is a CSP that uses default-src * because a vendor asked nicely.
The third mistake is copying API Access-Control headers onto the document and calling it CSP.
Free audit the URL you own
RoastMyOpsec is a defensive public-surface roast: headers, cookies, sensitive paths, and more — no exploit payloads. Start with the free audit, then open the vault if the blurred findings look expensive.
Free audit nowFAQ
- What security headers does a public website need first?
- HSTS, framing controls, nosniff, Referrer-Policy, Permissions-Policy, then CSP — CSP last only because it is the easiest to break, not because it matters less.
- Can I set these in meta tags instead of HTTP headers?
- Some CSP and referrer features have meta equivalents, but HSTS and X-Frame-Options do not. Prefer HTTP headers at the edge so every response is covered.
- Will a header checklist get me a 10/10 OPSEC score?
- No. Score also depends on TLS, cookies, sensitive paths, and client-side secrets. Headers are the first adult supervision, not the whole roast.