The idea, and the first version that didn't work

The first instinct is the obvious one: list the places scripts are allowed to come from. That's an allowlist CSP, and CSP Level 1 (2012) was built on it — script-src naming the trusted hosts, the browser refusing everything else. It looks like this:

Content-Security-Policy:
  script-src 'self' https://apis.google.com https://cdn.example;
  object-src 'none';

A script from apis.google.com runs; the same script served from evil.example is blocked. Reasonable-looking — and, as the next section shows, almost useless.

In 2016 a team at Google measured how well this worked across more than 1.6 million sites, and the answer was: almost not at all. The paper's title is "CSP Is Dead, Long Live CSP!", and its finding is brutal — 94.72% of all distinct policies were trivially bypassable, and *99.34% of hosts with a CSP used policies that offered no benefit against XSS at all.*

The mechanism is a gadget: a script on an allowlisted domain that an attacker can repurpose. The clearest example is a JSONP endpoint, which wraps its JSON response in a caller-named function so the browser can run it as a script. The caller picks the name — and the endpoint echoes it back verbatim:

GET https://trusted-cdn.example/api?callback=alert(document.cookie)//
→  alert(document.cookie)//({"data": …})

That response is served from trusted-cdn.example, so script-src trusted-cdn.example waves it straight through — and the attacker has just run alert(document.cookie) on your origin. The // comments out the rest.

An old AngularJS copy on an allowlisted host is the same story by another route: feed it the right markup and it turns benign-looking HTML into code. The study found 14 of the 15 most-commonly-allowlisted domains hosted a gadget like this. Allowlist your analytics vendor and you've very likely allowlisted a way to run anything. The allowlist isn't merely hard to maintain — it's insecure by construction.

The fix: vouch for scripts, don't trust their address

The repair inverts the question. Stop asking where a script came from. Start asking did I, the server, vouch for this exact script? The mechanics predate the paper: nonces and hashes were already standardized in CSP Level 2 (Candidate Recommendation, July 2015) and shipping in browsers — the paper itself notes the approach was "already defined by the CSP specification and available in major browser implementations." What the paper contributed was the measurement, and one new keyword: it proposed 'strict-dynamic', which CSP Level 3 adopted.

Two mechanisms do the vouching. A nonce is a random token the server generates fresh for every single response and stamps on both the policy and the script tags it trusts; the browser runs only scripts carrying that response's nonce. A hash (sha256-…) vouches for one specific inline script by the fingerprint of its contents — the same content-hash move that Subresource Integrity makes for an external script. (If a nonce is the playground's daily wristband, a hash is admission by biometrics — not a token you carry but the script's own fingerprint, computed from its exact bytes; change one character and it no longer matches.) Either way, an injected <script> — which the attacker can't nonce, because they don't know this response's random value, and can't hash-match, because its bytes differ — simply doesn't run.

Those two mechanisms give three real-world flavors of strict policy, and which one fits depends on how your HTML is served:

• Nonce-based. A fresh random token per response, threaded into every script tag server-side. The natural fit when the HTML is generated per request (a server-rendered app, a page assembled by middleware) — you already have a render step to stamp the nonce into.
• Hash-based. No token at all: the policy lists a sha256- of each trusted inline script's bytes. Because a hash is stable, the HTML can be statically built and edge-cached — which is why a static-site generator or a framework-built front-end reaches for hashes. (It's what this site uses; the policy snapshot used for this article is hash-based, for exactly the caching reason a nonce can't survive.)
• Hybrid. Both at once — a nonce for the per-response root script plus hashes for the build-time inline ones. The nonce covers what's dynamic; the hashes cover what's baked in.

The rest of this piece works through the nonce mechanics in detail, because the nonce is where the sharp edges live — but everything about vouching, strict-dynamic, and the traps applies to the hash and hybrid forms too.

const script = document.createElement("script");
script.src = new URLSearchParams(location.search).get("plugin");
document.head.append(script);

const plugins = new Map([
  ["charts", "/js/charts.js"],
  ["search", "/js/search.js"],
]);

const requested = new URLSearchParams(location.search).get("plugin");
const selected = requested === null ? undefined : plugins.get(requested);
if (selected !== undefined) {
  const script = document.createElement("script");
  script.src = selected;
  document.head.append(script);
}

Reading a strict policy

Here is a worked policy assembled from the CSP3 specification and web.dev's strict-CSP guidance. It is a teaching specimen, not a policy copied from a production site: the nonce and hashes are placeholders, and the resource and reporting endpoints are deliberately generic so the structure stays visible.

default-src 'none';
script-src 'nonce-{RANDOM}' 'strict-dynamic'
           'sha256-{HASH}' 'sha256-{HASH}'
           'unsafe-inline' https:;
object-src 'none';
base-uri 'none';
frame-ancestors 'none';
require-trusted-types-for 'script';
trusted-types default;
report-uri https://example.com/csp-report;
report-to csp-endpoint;
upgrade-insecure-requests;

Read it from the top and the design reveals itself.

default-src 'none' is the posture: deny everything by default, then grant back only what's named. You start from zero, not from "the web."

The script-src line is the whole graceful-degradation trick stacked into one directive, and it's worth slowing down on, because it's designed to be read by three different generations of browser at once. A CSP3-capable browser sees the nonce and strict-dynamic and uses only those — ignoring unsafe-inline (because a nonce is present) and https: (because strict-dynamic is). A CSP2 browser doesn't understand strict-dynamic, so it honors the nonce and the hashes. An ancient CSP1 browser understands neither and falls back to unsafe-inline https: — weak, but it keeps the page working. One line, three policies, strongest one wins where it's understood. As Google's own guidance puts it: browsers that support strict-dynamic "ignore the https: fallback, so this won't reduce the strength of the policy."

Don't take the stacking on faith — judge it. The strict-policy exercise turns that script-src line into a truth table: the chips toggle each source expression in and out, and six script scenarios are re-verdicted live under whichever browser generation you pick.

object-src 'none' and base-uri 'none' are the quiet, essential hardening. object-src "disable[s] dangerous plugins"; base-uri "block[s] the injection of <base> tags," which would otherwise let an attacker rewrite where every relatively-named script loads from. Skip these two and a nonce-based policy is still bypassable — which is exactly the kind of subtle hole the CSP Evaluator exists to catch.

require-trusted-types-for 'script' is the deepest line. Nonces stop an attacker from injecting a script tag; Trusted Types stop them from reaching a DOM XSS sink like innerHTML with a string at all — those functions "only accept non-spoofable, typed values created by Trusted Type policies, and reject strings." It closes the injection class that CSP's script rules can't see.

The CSP Evaluator: catching the subtle holes

You don't have to eyeball a policy for these traps. CSP Evaluator — built by the authors of the 2016 research, hosted by Google — exists precisely to "identify subtle CSP bypasses which undermine the value of a policy." Paste a policy in and it grades each directive, flagging the failure modes the research cataloged.

Run the policy through it and the strict pieces pass: a nonce is present, strict-dynamic is set, object-src and base-uri are locked to 'none'. Configurations even roughly this careful were vanishingly rare in the 2016 study — in its words, "only 9.37% of the policies in our data set have stricter configurations and can potentially protect against XSS" (that is, they merely avoided the trivially fatal keywords; strict-dynamic didn't yet exist in that corpus) — "however, we find that at least 51.05% of such policies are still bypassable." Half of even the careful ones.

What the absence has cost

The demonstrations above are research. The bill below is a matter of public record, and it is worth reading closely because it does not show a strict CSP as a magic wand.

Between 21 August and 5 September 2018, someone modified a JavaScript file served by British Airways so that payment details typed by customers were copied to a server the attacker controlled, on a domain chosen to read as the airline's own. The ICO's penalty notice records 429,612 people affected and a £20m penalty — reduced from an announced £183.39m — and finds separately that card data had been logged in plaintext since 2015, so the script is not the whole story.

The precise part is which half of a policy would have applied. The modified file was first-party: it was already on the page, already allowed, and a nonce vouches for the tag rather than for the file's contents, so script-src would have let it run. What stood between the skimmer and the attacker was a connection to an unfamiliar host — and connect-src is the directive that refuses exactly that, regardless of which script asks.

That is the argument for writing the whole policy rather than the famous half of it. A team that ships script-src and leaves connect-src unset has built the control that would not have applied here and skipped the one that would.

Why almost no one has this

The deployment record is sobering. Strict CSP is well-specified, tooled, and documented — and strict CSP remains vanishingly rare. The measurements are consistent across years and research groups.

First, most sites have no CSP at all. The HTTP Archive Web Almanac tracks adoption climbing only slowly: the 2024 security chapter reports the CSP header on 19% of hosts, up from 15% in 2022, and the 2025 chapter puts it at 21.9% on its own page-based measure. A header that has existed for well over a decade still misses roughly four sites in five.

Second, of the sites that do have a CSP, the strict mechanisms are still a minority — and almost all of them keep the weak unsafe-inline keyword that a strict policy is supposed to neutralize. The 2024 Web Almanac reports the following shares among sites that send any CSP:

The independent NDSS 2020 measurement put the same finding starkly: "insecure practices are present in 90% of policies, whereas secure practices like nonces or hashes reach less than a 5% adoption rate." It also found CSP is increasingly deployed for other purposes entirely — 58% of CSP-using sites used it for something other than restricting scripts.

Why the gap? Because a strict CSP fights how real pages are built. Inline event handlers (onclick"…") and =javascript: URLs stop working and must be refactored out — and the spec's own escape hatch for that case is worth knowing precisely, because it is easy to reach for and hard to give back. The nonce has to be freshly generated server-side and threaded through the templating system into every script tag — which is awkward for the statically-served, framework-built front-ends that dominate in static deployments (those reach for hashes instead). Trusted Types asks you to route every DOM-sink call through a typed policy, and any third-party library that touches innerHTML the old way breaks until it's wrapped. The Trusted Types point quietly reshapes which libraries you let developers adopt at all: a dependency that eval=s, injects its own inline scripts, or writes raw =innerHTML is no longer a free choice under a strict CSP. I've drawn that out as a decision tree — Can I Use This Library? — for deciding, per dependency, whether to adopt it, wrap it, sandbox it, or walk away. None of this is conceptually hard. All of it is a great deal of careful, unglamorous work against a codebase that wasn't built expecting it — which is why a correct strict CSP remains, mostly, a thing large security teams do and others admire from a distance.

<button onclick="myScript()">Submit</button>

Content-Security-Policy: script-src 'unsafe-hashes' 'sha256-{HASH-OF-myScript()}'

Deploying one without breaking your site

Teams stall because they fear the switch-flip, not because they reject a strict CSP: turn on default-src 'none' and watch half the page go dark, in production, with no map of what broke. There's a way to deploy that avoids that moment. The order matters:

1. Deny everything by default. Start the policy from default-src 'none' and grant back only what the site actually uses — the inverse of allowlisting your way up from "the web." You want the final, strict policy from the first line; you're just not going to enforce it yet.
2. Turn on report-only mode. Ship that strict policy under the Content-Security-Policy-Report-Only header instead of Content-Security-Policy. In this mode the browser enforces nothing — every page keeps working exactly as before — but it reports every resource the policy would have blocked, to the reporting endpoint you name. You get a complete, real-traffic inventory of violations without a single user seeing a broken page.

Reporting-Endpoints: csp-endpoint="https://example.com/csp-report"

Content-Security-Policy-Report-Only:
  default-src 'none';
  script-src 'nonce-…' 'strict-dynamic';
  …
  report-uri https://example.com/csp-report;
  report-to csp-endpoint;

1. Fix what the reports show. Now the work is driven by data, not guesswork: each violation is a real thing to refactor — an inline handler to move into a nonced script, a javascript: URL to rewrite, a forgotten third-party host to account for. Fix, redeploy, watch the report volume fall. Because nothing is enforced, you can do this at your own pace, on live traffic, with real user behavior surfacing the long-tail cases a staging environment never would.
2. Flip to enforcing. When the reports go quiet — when the only violations left are ones you understand and have decided to accept — rename the header from …-Report-Only to Content-Security-Policy. Nothing about the policy changes; you're just turning enforcement on for a policy you've already proven fits the site. The switch-flip that teams fear becomes a formality, because you've already watched this exact policy run against production for weeks.

The report sink doesn't have to be elaborate: a small endpoint that logs the JSON and drops it is enough to start. (This site's own is a tiny edge function that rate-limits, logs one line per report, and samples a subset to a metrics store.) The point of the whole sequence is that it converts the one genuinely scary part of CSP — will this break production? — into an observed fact instead of a leap of faith.

The shape of the whole thing

Step back and CSP is one idea, learned the hard way. The first version asked the wrong question — where is this script from? — and a domain you trust turned out to be a domain an attacker can borrow. The fix was to ask the right question — did I vouch for this exact script? — answered with a per-response nonce, trust that propagates through strict-dynamic, and Trusted Types guarding the DOM sinks underneath. The tooling to verify it exists; the standard is settled. The only thing missing, on almost every site, is the will to do the work — which is the real reason XSS is still with us.

Lessons

• CSP changes the browser's default from "run everything in the page" to "run only what the server vouches for" — a defense against XSS.
• Allowlists of trusted domains failed: the 2016 study found 94.72% of policies trivially bypassable, because trusted domains host gadgets (JSONP, old AngularJS) that run attacker code.
• The fix is to vouch per-script: a fresh per-response nonce (or a content hash), with strict-dynamic propagating that trust so no host allowlist is needed; supporting browsers ignore the allowlist entirely.
• Nonce, hash, or hybrid: nonces suit per-request HTML, hashes suit statically-built and edge-cached HTML (this site's is hash-based), and a hybrid policy can use a nonce for dynamic content plus hashes for baked-in scripts.
• A backward-compatible strict policy can layer three browser generations in one script-src (nonce + strict-dynamic + unsafe-inline https: fallback), pairs it with object-src 'none' / base-uri 'none', and adds Trusted Types for DOM sinks. CSP Evaluator catches the subtle holes.
• Deploy it report-only first: ship the final strict policy under Content-Security-Policy-Report-Only, fix what the violation reports show on real traffic, then rename the header to enforce — no production switch-flip, no guesswork. Send report-to (with Reporting-Endpoints) alongside the deprecated report-uri until support is universal.
• 'unsafe-hashes' is the legacy migration hatch, not a destination: plain hashes don't authorize inline event handlers, and the keyword that does authorizes a code fragment rather than a place, so a blessed handler string can be reattached anywhere in the document.
• AI changes the economics, not the execution primitive: a model can synthesize and adapt an injection payload, but it cannot mint a nonce or hash match. Strict CSP remains the browser backstop; tight resource directives, safe rendering, Trusted Types, narrow tools, input validation, and server authorization are still required when trusted code acts as a confused deputy or generated output tries to exfiltrate data through a browser request.
• Almost no one deploys it: ~22% of sites send any CSP (2025, up from ~11% in 2022); of those, ~20% use nonces and ~10% strict-dynamic (2024) — because a strict CSP is a lot of unglamorous work against code that wasn't built for it.

Practice

References

1. Joe Medley. “Content security policy.” web.dev. — the mechanism explained from first principles — the best starting point for a reader new to CSP
2. Lukas Weichselbaum. “Adopting a strict CSP.” web.dev. — and csp.withgoogle.com — Google's deployment guidance
3. “CSP Evaluator.” — · its source — paste a policy, see the bypasses
4. Weichselbaum et al.. “CSP Is Dead, Long Live CSP!.” ACM CCS, 2016. — the allowlist-insecurity study
5. Lekies et al.. “Code-Reuse Attacks for the Web: Breaking XSS Mitigations via Script Gadgets.” ACM CCS, 2017. — the residual bypass — gadgets in vouched-for frameworks
6. W3C. “CSP Level 3.” W3C. — and MDN's CSP guide — the spec and the reference
7. MDN. “CSP: script-src.” MDN. — source expressions, including 'unsafe-hashes' and why hashes alone miss event handlers
8. MDN. “CSP: report-uri.” MDN. — the deprecation and the send-both migration pattern
9. W3C. “Fetch Metadata Request Headers.” W3C Working Draft, 2025. — the request-admission boundary that sits beside CSP
10. NIST. “Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations.” NIST AI 100-2e2025, 2025. — prompt injection, agent hijacking, arbitrary code execution, and exfiltration
11. Google Chrome. “Content scripts.” Chrome for Developers. — isolated and main-world extension execution boundaries
12. Google. “Mitigating prompt injection attacks in AI systems.” Google Online Security Blog, 2025. — layered prompt, rendering, URL, and human-confirmation defenses
13. Johann Rehberger. “Google Bard Data Exfiltration.” Embrace The Red, 2023. — poisoned Google Doc, Markdown image exfiltration, and a CSP-allowed Apps Script relay
14. Johann Rehberger. “Data Exfiltration in Azure OpenAI Playground.” Embrace The Red, 2023. — pasted prompt to automatically rendered image request
15. Johann Rehberger. “ChatGPT Data Exfiltration: First Mitigations Implemented.” Embrace The Red, 2023. — external-image exfiltration and early client-side URL mitigations
16. Michael Bargury et al.. “EchoLeak: The First Zero-Click Prompt Injection Exploit Turning Microsoft 365 Copilot Against Itself.” AAAI 2026 Spring Symposium Series, 2026. — CVE-2025-32711; crafted email and a CSP-allowed Teams image proxy
17. Noma Security. “ForcedLeak: Agent Risks Exposed in Salesforce Agentforce.” Noma Security, 2025. — CRM prompt injection and an expired CSP-allowlisted domain
18. Johann Rehberger. “Security Keeps Google Antigravity Grounded.” Embrace The Red, 2025. — poisoned source content, image exfiltration, and tool-mediated command execution
19. “HTTP Archive Web Almanac: Security.” — the adoption measurements

Mangalapilly, Y. J. (2026, July). Trust No Script. Saṃhitā Notes. https://yesudeep.com/blog/trust-no-script/

@online{mangalapilly2026trust,
  author  = {Yesudeep Jose Mangalapilly},
  title   = {Trust No Script},
  journal = {Sa\d{m}hit\=a Notes},
  year    = {2026},
  month   = {July},
  url     = {https://yesudeep.com/blog/trust-no-script/},
  urldate = {2026-08-12},
}

Yesudeep Jose Mangalapilly. “Trust No Script.” Saṃhitā Notes, 2026. https://yesudeep.com/blog/trust-no-script/.

TY  - ELEC
AU  - Mangalapilly, Yesudeep Jose
TI  - Trust No Script
T2  - Saṃhitā Notes
PY  - 2026
UR  - https://yesudeep.com/blog/trust-no-script/
Y2  - 2026-08-12
ER  -