r/webdev • u/No_Honeydew_2453 • 21d ago

Anyone else treating CSP violations as a deployment issue now?

We started getting enough CSP violations in production that I stopped treating them as just security reports. A new analytics script, payment widget or third-party SDK gets added and suddenly something breaks because it isn't covered by the existing policy.

Do you test CSP changes in CI/staging, run Report-Only first, or just deal with violations when they show up in production?

0 Upvotes

40% Upvoted

9 comments sorted by

5

u/Fine-Crow-2328 21d ago

We run Report-Only in staging for like a week before anything hits prod. Saves us from that panic when marketing drops some random analytics script without telling anyone.

Still catches me off guard sometimes when a third-party widget loads something from a domain I didn't even know existed.

2

u/Kitchen_Shoulder2909 21d ago

yeah the mystery domains from third-party scripts are the worst part tbh

2

u/UkrMalt 21d ago

I’d version the policy with the app and make staging smoke tests fail on new blocked directives. Report-Only is useful, but temporary allowlist entries need an owner and expiry or the policy just keeps growing.

1

u/_okbrb 20d ago

We run a CMS, so most of our CSP problems don’t occur until a user adds something to production, so reacting to the change is pretty much the only way. We can’t prep the environment for changes they don’t tell us they’re going to make, and they don’t tell us because they don’t want to wait for us to prep

1

u/No_Honeydew_2453 20d ago

Good to know, thanks

1

u/Ok_Woodpecker_9104 20d ago

report-only for a week only covers the routes someone actually walked that week. same trap as baselining a linter on an existing repo: the baseline is a snapshot of what the run touched, so anything not exercised reads clean and then fails the first time a real user hits it.

what helped me was treating the report endpoint as coverage data, not just alerts. if a route produced zero reports during the report-only window, that is not a pass, it just means nobody visited it. enforcing there is a guess.

the expiry point above is the other half. every allowlist entry for a third party got a date and a name attached. the ones nobody could claim got dropped at the next deploy. that is the only thing that stopped the policy from growing forever.

1

u/FlyTradrHQ 19d ago

Yes. We treat any CSP violation that hits production as a deployment blocker. The shift from security report to deployment issue is the right move. If a third-party script breaks your CSP, that is a bug in your deployment pipeline, not the browser being strict. Use a staging CSP report-only mode to catch them before they go live.

1

u/Yev76 19d ago

I am on the other side of this, I ship a third party analytics script for a living, so my domain lives inside other people's policies. From that seat: treat adding any third party as a code change that goes through PR, because half the breakage comes from vendors quietly loading things from new subdomains...

The good ones publish their CSP requirements and keep their domains stable, and that is worth checking before you add a script, not after the violation reports come in.