Our production CSP reports have become frequent enough that I'm no longer treating them as purely security notifications. Adding an analytics script, payment widget, or third-party SDK can unexpectedly break functionality when its domains aren't included in the current policy. How are you handling CSP changes—testing them in CI or staging, using Report-Only before enforcement, or fixing violations after they appear in production?
4 Answers
We run CSP in Report-Only mode in staging for about a week before enforcing changes in production. That usually catches surprise analytics scripts and widgets before they cause an outage, although third-party code can still load from unexpected domains.
For a CMS, some violations are impossible to predict because users can add content or integrations directly in production. In that situation, reacting quickly is part of the workflow, but it helps to monitor reports and make the approval process as lightweight as possible.
A week of Report-Only data only covers the routes and features people actually used. A route with no violations might simply have had no traffic, so treat the report endpoint as coverage data rather than proof that the route is safe. Also give every third-party allowlist entry a named owner and removal date; deleting unclaimed entries during later deployments is what keeps the policy from growing indefinitely.
Version the CSP alongside the application and make staging smoke tests flag newly blocked resources. Report-Only is helpful, but every temporary allowlist entry should have an owner and an expiration date. Otherwise the policy slowly turns into a permanent list of exceptions.
The mystery domains introduced by third-party scripts are definitely the hardest part to track down.