Roll out a Content Security Policy safely

01Prepare a policy your site can use

Content Security Policy lets a site restrict resources and browser behaviour. A well-designed policy can help reduce the impact of certain injection and framing attacks. Its presence alone does not establish that it is effective, and a generic policy can break a working application. Give this checklist to the developer or platform owner who can test and deploy changes.

02Implementation checklist

1. Inventory scripts, styles, fonts, images, frames and external connections used by real pages. Include payments, login, support widgets and consent-dependent resources.
2. Design the policy for the framework and hosting platform. Review whether nonces or hashes are appropriate; avoid broad permissions simply to silence reports.
3. Test in staging, then use Content-Security-Policy-Report-Only where appropriate to observe violations without enforcing that policy. Keep any existing enforcing policy in mind.
4. Collect reports through a controlled endpoint if you configure reporting. Restrict access and review what page URLs or other information the reports may contain.
5. Investigate legitimate violations and unexpected sources. Browser extensions and third-party changes can create noise; check representative user journeys yourself.
6. Enforce the reviewed policy in a controlled release. Test forms, sign-in, checkout and embedded services on supported browsers, and keep a rollback route.
7. Revisit the policy when dependencies or third-party services change. Record the owner and the last application-level verification.

03Evidence of completion

Keep the deployed header, the pages tested, the release date and any unresolved exceptions. A public scan can observe a response header; application testing establishes whether important journeys still work and whether the policy matches the intended restrictions.