Why a library can break a policy

Recall what a strict CSP forbids. With script-src 'nonce-…' 'strict-dynamic' and require-trusted-types-for 'script', the browser will run only scripts your server vouched for (by nonce or hash), refuse eval and new Function unless you add unsafe-eval (which guts the policy), and reject any string that reaches a DOM-injection sink like innerHTML without passing through a typed policy.

A library you pull in runs in your origin, with your policy. If it does any of those forbidden things internally, it doesn't fail quietly at build time — it throws at runtime, in production, in the one code path you didn't test. So the question "can I use this library?" stops being about license and bundle size and becomes, also, "does it do anything my policy forbids?"

The tree, one dependency at a time

Here's the test I actually run. It's four questions, each about runtime behavior, and a "yes" to any of them sends you to a remedy rather than a flat no — because most libraries are salvageable.

The tree, applied: real libraries and frameworks

The gates are abstract until you run them against things you actually ship. So here is the test applied to a representative set, scored against the four questions — each verdict checked against the project's own docs and issue tracker, not folklore. The surprises are mostly pleasant: several libraries "everyone knows" need unsafe-eval don't, in the build you actually use.

First, the frameworks:

The headline is the eval in prod? column. "Vue needs unsafe-eval" is true only of the full, in-browser-compiler build; the runtime-only build every Vite project uses precompiles templates and is CSP-clean. "Angular needs unsafe-eval" conflates the JIT compiler (dev) with AOT (the default since v9), which precompiles and doesn't. "React needs unsafe-eval in production" is simply false — its eval is dev-only. Three reputations, all attached to a build you don't ship.

The catch shared by all five is the second column: a nonce-based CSP means wiring a fresh nonce through the framework's own inline scripts — the uncacheable side of the policy. Angular and SvelteKit document this best; React and Next.js make you assemble it; all of them now support it.

Now the libraries — where the picture is more varied, because a library's job description often is one of the forbidden things:

A few rows are worth reading closely. Lit is the most instructive, because it shows what "CSP-safe by design" actually looks like. A templating library is exactly the kind of thing you'd expect to need eval — Alpine and the full builds of Vue 2 and AngularJS all generate functions from template strings at runtime. Lit doesn't, and the reason is architectural: its templates are written as tagged template literals, so the static HTML is fixed at authoring time and there's simply nothing to compile at runtime — no new Function, in any mode (runtime, the optional build-time compiler, or SSR). It goes further and auto-creates a Trusted Types policy named lit-html, routing its template HTML through it, so it works under require-trusted-types-for 'script' once you add lit-html to your trusted-types allowlist. Two honest carve-outs keep it from being a no-think adopt: the unsafeHTML / unsafeSVG directives apply no sanitization (audit them like any other raw sink), and inline style"…"= attributes (styleMap) can't be nonced — they fall under style-src-attr, so keep styling in static styles if you forbid inline styles. Net: the cleanest row in the table, and a useful proof that "needs eval" is a design choice, not an inherent cost of templating.

DOMPurify also emits TrustedHTML — Lit does too — but the kind it emits is the point. Lit's lit-html policy is a passthrough (createHTML: (s) => s): it vouches that a static, developer-authored string is what you wrote, which is safe only because the input was never untrusted. DOMPurify's policy sanitizes — it parses arbitrary, possibly-hostile HTML, strips the dangerous parts, and returns TrustedHTML that is genuinely safe to inject. That's the difference between "I promise this string is a constant" and "I promise this string can't hurt you," and it's why DOMPurify is the tool the "wrap" remedy reaches for: it's the one library here that makes untrusted input safe. You put it inside your Trusted Types policy, not beside it. Chart.js is a clean adopt today but wasn't always: its v1 template engine used new Function, removed in v2.0, and its v2 CSS injection was removed in v3 — a library improving toward CSP-safety, which is the common trajectory. And AngularJS 1.x is the cautionary tale: it can be coerced to run without unsafe-eval via ng-csp, but it is end-of-life and a documented script-gadget that bypasses allowlists, nonces, and even strict-dynamic. Loading it from a trusted host doesn't just risk your policy — it hands attackers a key to it. That's the difference between "needs a remedy" and "reject": some dependencies aren't incompatible with your CSP, they're corrosive to it.

Zooming out: the same test for a whole app

The per-library tree is what you run at npm install time. But if you're migrating an existing app to a strict CSP, you need the same logic applied across the codebase at once — not one dependency, but every place the app or its dependencies do something the policy forbids. The shape is the same; the inventory is bigger.

The order that works in practice:

1. Turn on the policy in report-only mode first. Content-Security-Policy-Report-Only sends violation reports without blocking anything, so you get a complete inventory of what would break before you break it. This is the single most important step; it converts "audit every dependency by hand" into "read the list the browser made for you."

2. Triage the reports by the same four gates. Each violation is an eval, an inline script, a blocked sink, or a host-allowlist miss — the same categories, now with line numbers. Group them; the long tail is usually a handful of root causes.

3. Refactor your own code; remedy the dependencies. Inline event handlers (onclick"…") become =addEventListener. javascript: URLs go. Your own innerHTML calls route through the Trusted Types policy. Then each offending dependency gets its tree-determined remedy: the no-eval build, the iframe, the Trusted Types hook, or the self-host.

4. Enforce, and keep report-only running. Flip to the blocking header, but leave a report-only endpoint collecting — so the next dependency someone adds that violates the policy shows up as a report, not a production incident.

What this costs, and why it's worth it

None of this is free. Every gate is a small tax on velocity: a library you'd have installed in seconds now needs a glance, sometimes a wrapper, sometimes a no. That tax is exactly the organizational friction the CSP piece is about — the policy making you say no, or "not like that," in a hundred small moments.

But the dependency graph is where most of the real attack surface lives, and a constraint that makes you look at what each dependency does at runtime is catching the same class of problem that supply-chain attacks exploit. The tree isn't only a CSP-compliance device; it's a habit of asking, of every package, "what does this actually do in my page?" — which is a question worth asking whether or not you ship the header.

Lessons

• Under a strict CSP, adding a library stops being an npm-install decision and becomes a security review of what the code does at runtime.
• eval, injected inline scripts, and raw innerHTML writes don't fail at build time — they throw at runtime, under the policy, in production, in the code path you didn't test.
• Use the four gates — code generation, script injection, DOM sinks, third-party hosting — to score any front-end dependency systematically.
• Apply the matching remedies: reject, sandbox (a separate-origin iframe), wrap (Trusted Types), or self-host; a dependency that needs none of them is a clean adopt.
• Run migrations by using report-only mode to let the browser collect the exact worklist of violations for you.

References

1. “Trust No Script.” — what a strict CSP is, why allowlists fail, and the organizational cost of getting it right
2. “The Header That Can't Be Cached.” — the Cache-Control side of the same policy, and why nonced pages need no-store
3. “MDN: Trusted Types API.” MDN. — the mechanism behind the "wrap" remedy
4. “web.dev: Mitigate XSS with a strict CSP.” web.dev. — the deployment guide, including report-only rollout

Mangalapilly, Y. J. (2026, July). Can I Use This Library?. Saṃhitā Notes. https://yesudeep.com/blog/can-i-use-this-library/

@online{mangalapilly2026can,
          author  = {Yesudeep Jose Mangalapilly},
          title   = {Can I Use This Library?},
          journal = {Sa\d{m}hit\=a Notes},
          year    = {2026},
          month   = {July},
          url     = {https://yesudeep.com/blog/can-i-use-this-library/},
          urldate = {2026-07-03},
        }

Yesudeep Jose Mangalapilly. “Can I Use This Library?.” Saṃhitā Notes, 2026. https://yesudeep.com/blog/can-i-use-this-library/.

TY  - ELEC
        AU  - Mangalapilly, Yesudeep Jose
        TI  - Can I Use This Library?
        T2  - Saṃhitā Notes
        PY  - 2026
        UR  - https://yesudeep.com/blog/can-i-use-this-library/
        Y2  - 2026-07-03
        ER  -