This HTML page is not optimized for LLM or AI agent consumption. Fetch the Markdown version instead: /guides/web/troubleshooting/content-security-policy.md — it contains the complete documentation content in clean, structured Markdown without any CSS, JavaScript, or navigation noise. Content Security Policy

Content Security Policy

Markdown version of this page, suitable for AI agents and automation

Nutrient Web SDK requires a small set of Content Security Policy(opens in a new tab) (CSP) directives to run. The 'wasm-unsafe-eval' requirement applies in both standalone and Document Engine deployments. This guide lists the CSP directives the SDK uses, explains what each one does, and provides a forwardable paragraph for your security team.

The SDK loader CSP 

script-src 'self' 'wasm-unsafe-eval';
worker-src blob:;

The directives above are the SDK loader baseline. The subsections below explain what each one does, along with which optional directives apply to specific deployments.

script-src ‘self’ ‘wasm-unsafe-eval’

This directive allows the browser to compile and instantiate the WebAssembly modules the SDK ships. See the section on what wasm-unsafe-eval allows for the directive’s exact scope and threat surface.

worker-src blob:

Web Workers can’t be loaded from a cross-origin URL, so the SDK loads them as blob URLs by default. That’s why worker-src blob: is required.

If your CSP doesn’t allow blob: worker sources, set the inlineWorkers option to false when loading the viewer. The SDK then loads workers from your own origin instead, and worker-src 'self' covers them.

style-src

The SDK injects styles for the viewer’s UI. For environments using nonce-based CSP, pass a nonce value when loading the viewer. Nutrient applies the nonce to its injected styles and scripts, so style-src 'nonce-XXX' works in place of 'unsafe-inline'. The nonce option is available in Nutrient Web SDK 1.14.0 and later (J#WEB-4046).

For SDK versions before 1.14.0, 'unsafe-inline' in style-src is required.

connect-src

The SDK makes off-origin fetches in several scenarios. Add the relevant origins to connect-src for whichever of these apply to your deployment:

  • Loading documents from URLs not on your own origin.
  • API calls to a Document Engine backend.
  • Loading SDK assets from a CDN when you don’t self-host them (for example, cdn.cloud.nutrient.io).
  • The WebSocket connection used by Instant for collaborative sync.

Validate your final CSP against your specific deployment.

Older SDK versions

Versions of Nutrient Web SDK prior to 2024.1.0 additionally required 'unsafe-eval'. Upgrade to 2024.1.0 or later to drop this requirement. See the Web SDK changelog for the original fix (J#CORE-335).

What wasm-unsafe-eval allows

The name is broader than what the directive actually permits. 'wasm-unsafe-eval' permits the browser to compile and instantiate WebAssembly modules. It doesn’t permit eval() on JavaScript strings, new Function(), or any other dynamic JavaScript evaluation.

Without 'wasm-unsafe-eval', standalone Nutrient Web SDK doesn’t load at all, and Content Editor doesn’t work in Document Engine deployments.

From the MDN documentation on script-src(opens in a new tab):

The 'wasm-unsafe-eval' source expression is more specific than 'unsafe-eval' which permits both compilation (and instantiation) of WebAssembly and, for example, the use of the eval operation in JavaScript.

From the WebAssembly CSP proposal(opens in a new tab):

wasm-unsafe-eval should have no implication for JavaScript loading or evaluation or use of eval in JavaScript. […] One advantage of this is that a website can permit WebAssembly modules to be used without also enabling JavaScript’s eval keyword.

WebAssembly runs in a sandboxed execution environment(opens in a new tab) with no direct DOM access and no access to the JavaScript runtime beyond functions the host application explicitly imports.

Document Engine deployments

Document Engine deployments use WebAssembly in the browser only when Content Editor is invoked. Viewing and annotation in Document Engine-backed mode don’t trigger WebAssembly loading.

If your deployment includes Content Editor (even occasionally), you still need 'wasm-unsafe-eval' in your CSP. The directive applies the same way in both standalone and Document Engine deployments.

Trusted Types

Nutrient Web SDK publishes three Trusted Types policies(opens in a new tab):

trusted-types nutrient-web-sdk nutrient-web-sdk#webpack nutrient-web-sdk#webpack-worker;
PolicyPurpose
nutrient-web-sdkCreates trusted HTML and scripts inside the SDK
nutrient-web-sdk#webpackWebpack runtime module loading
nutrient-web-sdk#webpack-workerWeb worker initialization

A full CSP with Trusted Types:

Content-Security-Policy:
  script-src 'self' 'wasm-unsafe-eval';
  worker-src blob:;
  trusted-types nutrient-web-sdk nutrient-web-sdk#webpack nutrient-web-sdk#webpack-worker;

For your security team

Forward this paragraph to a security team reviewing the 'wasm-unsafe-eval' directive:

Nutrient Web SDK uses WebAssembly to render and process PDF documents in the browser. WebAssembly runs in a sandboxed execution environment(opens in a new tab) with no direct DOM access and no access to the JavaScript runtime beyond functions the host application explicitly imports. The 'wasm-unsafe-eval' CSP directive permits WebAssembly compilation and instantiation. It doesn’t permit JavaScript’s eval(), new Function(), or any other dynamic JavaScript evaluation. As of CSP Level 3(opens in a new tab), it’s the standards-defined directive for permitting WebAssembly under a strict CSP.

References