Map the browser dependencies
Start with the origins used for scripts, styles, images, frames and browser requests. Include less visible dependencies such as embedded support widgets. Check representative pages rather than assuming the homepage contains every integration.
Security headers have different jobs. A Content Security Policy controls permitted resource behaviour; other headers address concerns such as framing or content-type interpretation. Use the browser documentation for each header rather than pasting a large unexplained configuration into the server.
Test before enforcing
For Content Security Policy, a report-only policy can help observe violations without enforcing that policy. It does not provide the protection of an enforced policy. Review the reports and browser console against expected page behaviour, and do not automatically allow every reported origin.
Build a test list that includes navigation, embedded content, forms and any payment or sign-in flow the site actually uses. Test pages with different layouts. A policy that works on the homepage can still block a script loaded only on an article or account page.
Verify the deployed response
Inspect headers at the public HTTPS endpoint after deployment. A reverse proxy or hosting layer may add, remove or duplicate a header. Keep a record of the intended policy and which layer owns it.
Make one policy change at a time, retain a known working configuration, and write down the symptoms that would trigger a rollback. Repeat the review when dependencies change. This guide describes the rollout process; the exact policy must be derived from the application’s needs.
Before you finish
- External origins inventoried
- Report-only distinguished from enforcement
- Representative journeys tested
- Public response verified
Technical reference
MDN: Content Security Policy