Debugging

Content Security Policy failures are easy to create and annoying to debug. They get even worse in production, where the browser console you rely on locally is now replaced by partial reports, CDN layers, injected third-party scripts, and users who only say “the page is broken.” I’ve dealt with this enough times to have a strong opinion: debugging CSP in production is less about one perfect tool and more about choosing the right signal. Browser errors, violation reports, header inspection, and controlled rollout all give you different slices of the truth. ...

Browser extensions make CSP debugging weird. You lock down script-src, remove inline code, add nonces, maybe even deploy strict-dynamic, and then someone on the team says: “Why is this extension still injecting stuff into our page?” Or worse: “Why is our app breaking only for users with ad blockers?” That confusion usually comes from one bad assumption: people expect a site’s CSP to control browser extensions the same way it controls page code. It doesn’t. ...

There’s nothing quite like deploying a CSP policy to production and watching your analytics break, your chat widget disappear, and your forms stop working. All at the same time. This guide is about surviving that experience and fixing things quickly. Where to Find CSP Violations Chrome Open DevTools (F12) → Console tab. CSP violations show up as red errors: Refused to execute inline script because it violates the following Content Security Policy directive: "script-src 'self'" For a more detailed view: DevTools → Application → Content Security Policy. This shows you the current policy and a log of violations. ...