Every team that has tried to ship a real Content Security Policy has the same story. The header goes out on a Tuesday, and by Wednesday the support queue is full of screenshots showing a blank chat widget, a dead analytics dashboard, or a checkout page that silently stopped loading its payment iframe. The instinct after that is to give up and ship unsafe-inline for everything, which defeats most of the point of having a policy at all.
CSP is not hard because the syntax is confusing. It is hard because most sites have accumulated ten to thirty third-party scripts over several years, nobody has a full inventory of what they do, and a surprising number of them load other scripts dynamically at runtime. Getting a policy live without breaking things is mostly a sequencing problem, not a security problem.
Why CSP Rollouts Usually Break Something
The failure pattern is almost always the same: someone writes a policy based on what they can see in the page source, ships it in enforcing mode, and immediately discovers scripts that only appear after a user interacts with the page. A support widget that lazy-loads on scroll. A payment SDK that only initializes at checkout. An A/B testing tool that injects its own script tags based on server-side flags.
None of these show up if you only read the initial HTML. A policy built from a single page load is a policy built from incomplete information, and enforcing mode punishes incomplete information immediately and visibly.
The fix is not a smarter first policy. It's accepting that you cannot know everything up front and building a process that surfaces the gaps before they hit real users.
Photo by Ekaterina Belinskaya on Pexels
Start with Report-Only Mode, Not Enforcement
The Content-Security-Policy-Report-Only header is the single most useful tool in this entire process. It evaluates your policy against every page load and reports what would have been blocked, without actually blocking anything. Nothing breaks. You just get data.
Run report-only for at least one full business cycle before you even think about enforcing. That means every day of the week, every marketing campaign, every seasonal promotion your ad platform runs, and every A/B test variant currently live. A policy that looks clean on a quiet Tuesday afternoon can fall apart the moment a Black Friday banner script fires.
Treat this phase as an inventory-building exercise, not a security milestone. You are not protecting anyone yet. You are finding out what you actually need to protect.
Auditing Every Third-Party Script Already Running
Before writing a single directive, pull a real list of what's loading. Browser devtools network tabs, a site crawler, and your report-only violation logs together will surface more than any single source alone. Cross-reference against your vendor contracts and tag manager configuration, because tag managers are notorious for injecting scripts that don't appear anywhere in your own codebase.
For each script, note three things: what domain it loads from, whether it loads additional scripts dynamically, and whether your team could explain why it's there if asked. That third question matters more than it sounds. Scripts nobody can explain are the ones most likely to get missed in the policy and most likely to be safe to remove entirely.
The OWASP cheat sheet series is worth keeping open during this pass. It lists the categories of risk a policy is actually meant to close off, which helps separate "we should allowlist this" from "we should question why this vendor needs this level of access at all."
Photo by panumas nikhomkhai on Pexels
This audit is also the moment to have an honest conversation with 137Foundry's web development team or your own engineers about which vendors are actually earning their keep versus which ones got added for a campaign two years ago and never removed.
Choosing Between Nonces, Hashes, and Allowlisted Domains
Domain allowlisting is the easiest to write and the easiest to defeat. If you allowlist a CDN domain that hosts other people's JavaScript too, you've effectively allowlisted anything that domain can serve, which is a much bigger surface than intended.
Nonces are stronger. A server-generated random value gets attached to both the CSP header and the script tag on each request, so only scripts your server explicitly approved for that page load can execute. The tradeoff is that nonces require your rendering layer to inject a fresh value per response, which is straightforward for server-rendered apps and more awkward for anything relying on aggressive full-page caching. Support for the newer directive keywords varies slightly across browser versions, so it's worth a quick check on caniuse if any of your traffic still comes from older browser builds.
Hashes work well for static inline scripts that never change, since the policy lists the exact cryptographic hash of the approved content. They break the instant someone edits the script by even one character, which is a feature during an incident review and an annoyance during routine maintenance.
Most production policies end up as a mix: nonces for first-party inline scripts, tight domain allowlisting for a short list of trusted vendors, and hashes for the handful of static snippets that genuinely never change. The MDN reference on the Content-Security-Policy header is the most reliable place to check exact directive syntax, since the spec has grown several new keywords over the past few years.
Handling Third-Party Scripts That Load Other Scripts Dynamically
This is where most policies quietly fail. A tag manager loads a marketing pixel, which loads a retargeting script, which loads a fraud-detection widget, and your policy only accounted for the tag manager's own domain. Each hop needs its own allowlist entry unless the vendor supports nonce propagation, which most don't.
Photo by Brett Sayles on Pexels
The practical answer is to isolate what you can. Where a vendor offers a server-side tagging option instead of client-side script injection, that removes an entire chain of dynamic script loading from your CSP surface in one move. Where that isn't available, budget extra time in your report-only phase specifically for chains like this, because they only reveal themselves after the parent script has actually executed in a real browser. Google's CSP Evaluator is a quick way to sanity-check a draft policy for exactly this kind of chained-loading gap before you commit to it.
Dealing with Inline Styles and Analytics Tags
Style directives get less attention than script directives, but they cause just as many false starts. Inline style attributes and <style> blocks are blocked by a strict style-src the same way inline scripts are blocked by script-src, and a lot of component libraries and email-style HTML widgets rely on inline styles by default.
Analytics tags deserve special scrutiny because they frequently use img tags as tracking pixels, which means img-src needs its own careful allowlist separate from your script policy. A policy that locks down scripts tightly but leaves img-src wide open has closed one door while leaving a data-exfiltration-shaped window open next to it.
Setting Up a CSP Violation Reporting Pipeline You'll Actually Read
A report-uri or the newer report-to directive sends violation reports to an endpoint of your choosing, but the reports are only useful if someone looks at them. Services like report-uri.com will collect and aggregate this for you if standing up your own ingestion endpoint isn't worth the effort yet. Raw CSP violation JSON is repetitive and noisy either way, full of duplicate entries from browser extensions and ad blockers that have nothing to do with your actual policy.
Photo by Mateusz Majewski on Unsplash
Filter aggressively before anyone has to read these. Group by blocked URI and directive, drop anything originating from known extension schemes like moz-extension:// or chrome-extension://, and set a threshold so a single user's misconfigured browser doesn't page anyone. A reporting pipeline that surfaces five real issues a week gets read. One that dumps three thousand rows a day gets ignored within a month.
Moving from Report-Only to Enforced Without a Rollback Scramble
Once report-only has run clean for a full cycle, enforce in stages rather than all at once. Start with the directives you're most confident about, typically object-src none and a tight base-uri, since almost nothing legitimate depends on either. Leave the noisier directives, usually script-src and style-src, in report-only a little longer if their violation counts haven't fully settled.
Keep the report-only header active alongside the enforced one during this transition. It costs nothing and gives you an early warning system for the next directive you're about to flip, since you'll see what would have broken before you actually break it.
Have a fast rollback path ready before you flip anything: a feature flag, a config value, or a one-line header change your on-call engineer can ship without a full deploy cycle. The goal is that if something does slip through, the fix takes minutes, not a rollback meeting.
"The teams that succeed with CSP treat it like a migration, not a switch. You don't flip a policy live and hope. You watch the report-only data until it stops surprising you, then enforce one directive at a time." - Dennis Traina, founder of 137Foundry
Maintaining the Policy as New Vendors Get Added
A CSP that isn't maintained decays the same way any allowlist decays: someone adds a new marketing tool, it silently fails because nobody remembered the policy exists, and the fastest fix under deadline pressure is loosening a directive rather than adding one scoped entry. Multiply that by a few quarters and the policy is Swiss cheese.
Bake a CSP check into whatever process already gates new vendor scripts, whether that's a tag manager approval step or a pull request template. The question is simple: does this script need a new entry, and can it be scoped to exactly the domain and directive it needs rather than reused from a broader existing allowlist entry. Reviewing this alongside 137Foundry's broader security and engineering work keeps the policy from becoming the one piece of infrastructure nobody owns.
When to Loosen a Rule vs When to Push Back on a Vendor
Not every violation means the policy is wrong. Sometimes it means a vendor's implementation is genuinely bad, relying on inline event handlers or eval-based code that a security-conscious CSP should be blocking anyway. Before loosening a directive to accommodate a script, ask the vendor if they have a CSP-compatible integration option. Most established vendors do, because enough of their customers have asked already.
Reserve rule-loosening for cases where the functionality is genuinely required and there's no compliant alternative. Every loosened directive is a small, permanent tax on your security posture, and they tend to accumulate quietly until an audit or incident forces someone to explain why unsafe-inline is sitting in a two-year-old policy with no comment explaining what it was for.
Getting CSP right is less about perfect syntax on day one and more about building a process that catches what you missed before your users do. Report-only mode, a real script inventory, and a reporting pipeline someone actually reads will get a strict policy live without the rollback scramble most teams remember from their first attempt.
