How do I deploy a strict Content-Security-Policy without breaking my site?

A strict Content-Security-Policy is the single most effective browser-side defense against cross-site scripting (XSS) — and one of the rarest headers in the wild. The reason is not ignorance but fear: a wrong CSP does not degrade gracefully. It breaks your site in front of users — scripts refuse to run, styles disappear, the checkout dies — and it does so the instant you deploy it. The cure for that fear has been part of the spec from the beginning: Report-Only mode. You deploy the policy as a dry run, let real browsers on real traffic tell you what would have been blocked, fix those findings, and only then enforce. This guide walks the whole path, and every step of it is free with IntoDNS.ai.

Why strict CSP matters — and why almost nobody ships it

XSS remains one of the most common web vulnerability classes. Server-side defenses — output encoding, templating, sanitization — fail at the margins: one forgotten template, one third-party widget. CSP is the second line of defense: even when an attacker finds an injection point, the browser refuses to execute the injected script.

That protection is only as strong as the policy, and most deployed policies are weak in one of two ways.

'unsafe-inline' in script-src. Most sites have inline scripts, the policy breaks without them, so 'unsafe-inline' gets added — and now any inline script executes, including the one the attacker injected. The header is present; the protection is gone.

Host allowlists. Listing trusted script origins (script-src 'self' cdn.example.com ...) sounds airtight but rarely is. The 2016 study "CSP Is Dead, Long Live CSP", which analyzed over 1.6 billion deployed policies, found that roughly 95% of allowlist-based policies could be bypassed — typically through JSONP endpoints or outdated framework copies hosted on the allowlisted CDNs themselves.

The modern answer is a strict CSP: a nonce (or hash) on every legitimate <script> tag, plus 'strict-dynamic'. Each HTTP response carries a fresh random nonce; only script tags carrying that nonce execute; 'strict-dynamic' extends trust to whatever scripts those trusted scripts load at runtime, which is what makes tag managers and embedded widgets workable. There is no host allowlist left to bypass.

Report-Only: the dry run built into the spec

CSP ships as two HTTP headers with identical syntax. Content-Security-Policy enforces — violating resources are blocked. Content-Security-Policy-Report-Only evaluates the exact same policy against every page load but never blocks anything. Instead, the browser sends a JSON violation report to the collector you name in the policy's report-uri directive (deprecated on paper, universally supported in practice) or via the newer Reporting-Endpoints response header with the report-to directive.

Each report tells you which directive failed, what was blocked (an origin, or a keyword like inline or eval), and on which page — exactly what you need to fix the policy before it blocks a real user. You can even run both headers at once: keep enforcing a relaxed policy while a strict candidate runs in Report-Only beside it.

This is the spec-blessed way to deploy CSP. Nobody writes a perfect policy from scratch — you write a candidate, observe, and iterate.

The three-step rollout

Step 1: generate a starter policy from a crawl

Run your site through the free CSP scanner — no signup needed. It crawls up to 20 same-origin pages, inventories every external script, style, image, font, and frame origin per CSP directive, flags weaknesses in any policy you already serve, and generates a ready-to-deploy starter policy in both enforce and Report-Only variants. The starter is built from a locked-down skeleton — default-src 'self', object-src 'none', base-uri 'self', frame-ancestors 'self', form-action 'self', upgrade-insecure-requests — and it never puts 'unsafe-inline' into script-src. If you would rather hand-build or tweak a policy directive by directive, the CSP generator does that.

Step 2: deploy as Report-Only and collect real traffic

A crawl sees only what a crawler sees. Real traffic includes logged-in pages, the page only the finance team opens, A/B variants, and the legacy widget on one forgotten URL. So create a free account and add a monitor on the CSP dashboard. Each monitor gets a personal report endpoint URL; append it to the starter policy with report-uri and ship the result under the Report-Only header name:

Content-Security-Policy-Report-Only: <your starter policy>;
  report-uri https://intodns.ai/api/csp-report/u/<your-token>

Nothing is blocked and users notice nothing. The endpoint accepts the legacy application/csp-report format and the newer Reporting API format, and aggregates reports by directive and blocked origin — fifty thousand identical violations show up as one row with a count, not as noise. Everything is free within fair-use limits: 3 monitors per account, 10,000 reports per monitor per day, and 30 days of retention.

Step 3: synthesize a strict policy from the evidence, then enforce

After about a day of real traffic — longer for low-traffic sites; cover at least a full week if usage varies by weekday — one click on the monitor page generates a policy from the collected violations, optionally merged with a fresh crawl of your site. Review it (origins observed only once are flagged so you can verify they are intentional), then change the header name from Content-Security-Policy-Report-Only to Content-Security-Policy. Keep the report-uri in the enforced policy: the monitor keeps listening, and a weekly digest email flags new violation patterns — a tag someone added, a CDN that changed hostnames — before they turn into silent breakage. The full background on how the monitor works is in the CSP monitor launch post.

Common pitfalls

Inline scripts and inline event handlers. The crawler and the violation reports will both surface these. The fix is a nonce on each inline <script> block, or moving the code to an external file — never 'unsafe-inline' in script-src, which nullifies the policy. Inline attribute handlers (onclick="...") cannot carry a nonce at all; refactor them to addEventListener calls in a nonced or external script.

Third-party tags that load more third parties. A tag manager loads whatever tags are configured inside it, and ad or analytics scripts routinely pull in further scripts from other origins. An allowlist chases a moving target forever. 'strict-dynamic' solves this structurally: the nonced loader is trusted, and everything it loads inherits that trust.

Testing on a staging site without traffic. Report-Only with no visitors collects nothing. The crawl covers a quiet staging environment, but violation reports only carry signal on a site with real users — deploy the Report-Only header in production, where it is guaranteed harmless.

Meta-tag CSP. A policy can be set in a <meta http-equiv> element, but with hard limits: frame-ancestors, report-uri, and sandbox are ignored there, and the Report-Only header has no meta equivalent at all. The whole monitor-first workflow requires a real HTTP header, set at the web server, CDN, or application layer. The security headers generator produces ready-to-paste configuration for the full header set around CSP, including HSTS and the rest.

A realistic before and after

Phase one, the crawl-derived starter deployed as a dry run with reporting:

Content-Security-Policy-Report-Only: default-src 'self'; script-src 'self'
  https://js.stripe.com https://cdn.jsdelivr.net; style-src 'self';
  font-src 'self'; img-src 'self' data:; object-src 'none';
  base-uri 'self'; frame-ancestors 'self'; form-action 'self';
  upgrade-insecure-requests;
  report-uri https://intodns.ai/api/csp-report/u/kF3n9vQ2hL8mPwXz

Phase two, the strict policy enforced after the reports came back clean:

Content-Security-Policy: script-src 'nonce-{RANDOM}' 'strict-dynamic'
  https: 'unsafe-inline'; object-src 'none'; base-uri 'self';
  frame-ancestors 'self'; form-action 'self'; upgrade-insecure-requests;
  report-uri https://intodns.ai/api/csp-report/u/kF3n9vQ2hL8mPwXz

Two details make the second policy work everywhere. The {RANDOM} nonce must be a fresh, unguessable value generated per HTTP response — a static string would let an attacker reuse it. And the https: and 'unsafe-inline' entries are deliberate backwards-compatibility fallbacks: a browser that understands nonces ignores 'unsafe-inline', a browser that understands 'strict-dynamic' ignores https:, and an old browser that understands neither falls back to them — no worse off than before.

When to use IntoDNS.ai

IntoDNS.ai covers this entire workflow without payment: the CSP scanner for the crawl and starter policy, the CSP dashboard for the report endpoint, violation aggregation, one-click strict-policy synthesis, and the weekly drift digest, and the CSP generator plus security headers generator for hand-tuning the result. The discipline itself — observe in report mode first, enforce only on evidence — is the same one that works for every gradually-enforced security control; the State of Email Security report benchmarks how domains fare at exactly that kind of rollout across web and email controls.