The five-line CSP rollout that actually works

The five-line CSP rollout that actually works

Content Security Policy is the highest-impact browser-level defense against XSS, and it is also the header most SaaS teams keep deferring. The problem is not that CSP is hard to write. The problem is that a badly written CSP breaks production in ways that are hard to catch in staging. Here is the pattern we use with our pen-test customers when they ask for a rollout playbook.

Step one — report-only mode

Ship the policy for two weeks before you enforce it. Content-Security-Policy-Report-Only tells the browser to log violations without blocking them.

Content-Security-Policy-Report-Only: default-src 'self'; script-src 'self' 'unsafe-inline'; report-uri /csp-report

Your /csp-report endpoint receives JSON POST bodies for every violation. Log everything. Do not try to filter yet.

Step two — inventory the violations

Real customer sites typically produce three categories of violations in the first week:

The third category is the point. CSP is doing its job before it enforces anything.

Step three — enforce

Flip the header name from Content-Security-Policy-Report-Only to Content-Security-Policy. That is the entire migration.

If you would like a deeper look at the security-header stack, our security headers cheat sheet for 2026 covers HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, and Permissions-Policy with the exact values to set. And if you want a snapshot of your own site's current headers, our free scan tool will pull one in three minutes.