A website security headers checklist should improve browser protections without breaking sign-in, checkout, analytics, media, or embedded tools. Inventory current responses, choose policies for the site's real architecture, test in a safe mode, and deploy changes in small steps.
Capture the current response headers
Test the home page, sign-in page, forms, checkout, API responses, downloads, and representative error pages. Record the final URL, status, and headers after redirects. Check both the main hostname and important subdomains because a policy on one response does not prove it exists elsewhere.
OWASP's HTTP Headers guidance covers controls including Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options, Referrer-Policy, frame protections, cross-origin policies, and secure cookie attributes (OWASP Cheat Sheet Series). Select headers based on the application rather than pasting an aggressive template into production.
Map required browser resources
List every script, stylesheet, font, image, frame, form destination, API connection, worker, and media source used by the site. Mark which are first-party and which belong to payment, support, analytics, video, or other vendors. Remove abandoned dependencies before allowing them in a long-term policy.
MDN explains that Content Security Policy controls which resources a browser may load and can report violations (MDN). Build directives from the inventory so the policy reflects actual needs.
Introduce CSP with observation
Start with `Content-Security-Policy-Report-Only` when practical. Exercise real user journeys and review violations. Separate required resources from browser extensions, stale pages, and unwanted injections. Tighten sources gradually, then enforce once critical paths are clean.
Do not assume a report-only policy blocks anything. It provides evidence for planning. When enforcement begins, keep the previous configuration and a fast rollback route. Test inline scripts, tag managers, payment widgets, consent tools, and error handling because these are common places for hidden dependencies.
Review the other protections
Confirm that HTTPS is stable before enabling a long HSTS policy. Review framing requirements before blocking all embedding. Set content types accurately and use nosniff protections where appropriate. Choose a referrer policy that balances privacy with legitimate attribution needs. Apply secure cookie attributes in the application that creates each cookie rather than trying to repair them blindly at an edge layer.
Use modern browser support data and the framework's current documentation. Retire obsolete headers rather than preserving them because an old scanner once requested them. A clean policy is easier to understand and maintain than a pile of contradictory values.
Test pages and workflows
Run automated checks, then complete manual journeys on current browsers and mobile devices. Inspect console errors, blocked requests, downloads, redirects, and embedded content. Verify that security headers also appear on errors and redirects where the platform supports them.
Check for duplicate headers from the application, load balancer, CDN, and hosting provider. Multiple CSP values combine restrictively, so an unexpected second policy can block resources even when another header appears to allow them (MDN).
Keep an owned baseline
Store the approved header set with an owner, rationale, test date, and deployment layer. Recheck after adding a vendor script, changing hosting, enabling a new payment flow, or updating the framework. Alert on unexpected removal or material policy changes.
Quick completion test
The review is ready to close when key routes return the intended headers, CSP has been observed before enforcement, required third-party resources still work, duplicate policies are understood, rollback is available, and the approved baseline has an owner.
Sources
- HTTP Headers Cheat Sheet — OWASP Foundation
- Content-Security-Policy header — MDN Web Docs