Content Security Policy

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 'self' 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 enables 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 ‘self’ 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.

The worker that converts Office documents (DOCX, XLSX, and PPTX) imports its runtime scripts from the location of the SDK assets. Firefox checks these imports against worker-src, so Office documents fail to open in Firefox unless worker-src allows that origin. The 'self' in the baseline covers SDK assets served from your own origin. When you load the assets from another origin, add that origin to worker-src as well.

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. Standalone deployments can use this option directly. Server-backed deployments can set it in shared configuration starting with Nutrient Web SDK 1.22.

In standalone deployments of Nutrient Web SDK 1.3.0 through 1.22.0, setting inlineWorkers only in NutrientViewer.load() doesn’t reach the worker that converts Office documents. That worker still starts from a blob: URL, and Office documents don’t finish loading. To open them without blob:, pass the same configuration, including a processorEngine, to NutrientViewer.preloadWorker() before loading the document:

const configuration = {
  container: "#nutrient-container",
  document: "document.docx",
  inlineWorkers: false,
  processorEngine: NutrientViewer.ProcessorEngine.fasterProcessing,
};

try {
  await NutrientViewer.preloadWorker(configuration);
  await NutrientViewer.load(configuration);
} catch (error) {
  console.error(error);
}

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). In 1.14.0, the browser still blocks one style the viewer injects under a nonce-only style-src. Starting with 1.15.0, the nonce covers every injected style.

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 synchronization.

Validate your final CSP against your specific deployment.

img-src

The viewer displays rendered pages as images loaded from blob: URLs, and it loads some images from data: URLs. This applies to both standalone and Document Engine deployments. If your CSP sets img-src, or sets default-src without img-src, allow both sources:

img-src 'self' data: blob:;

Without blob:, pages stay blank and the console reports Page 0 render failed. Without data:, pages render, but Chromium and Firefox report CSP violations for the blocked data: images.

font-src

The SDK assets include the fonts used for typed electronic signatures. When you load the assets from another origin, such as a CDN, and your CSP sets font-src or default-src, add that origin to font-src. Otherwise, the browser blocks these fonts. Documents still load and render without them.

Older SDK versions

Versions of Nutrient Web SDK prior to 2024.1.0 (J#CORE-335), and versions from 2024.8.0 up to, but not including, 1.5.0 (J#WEB-2924), additionally required 'unsafe-eval'. Upgrade to 1.5.0 or later to drop this requirement. See the Web SDK changelog for details.

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. It has 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 four Trusted Types policies(opens in a new tab): the three nutrient-web-sdk policies, starting with 1.11.0, and dompurify (1.14.0 and later). List them in the trusted-types directive, together with the 'allow-duplicates' keyword explained below:

trusted-types nutrient-web-sdk nutrient-web-sdk#webpack nutrient-web-sdk#webpack-worker dompurify 'allow-duplicates';

Policy	Purpose
`nutrient-web-sdk`	Creates trusted HTML and scripts inside the SDK
`nutrient-web-sdk#webpack`	Webpack runtime module loading
`nutrient-web-sdk#webpack-worker`	Web worker initialization
`dompurify`	Sanitizes rich text in annotations

A full CSP with Trusted Types:

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

Starting with Nutrient Web SDK 1.14.0, the browser reports a CSP violation when the viewer displays a text annotation and dompurify isn’t in the list. Starting with 1.15.0, the text of rich text annotations doesn’t render without dompurify if your CSP also sets require-trusted-types-for 'script'.

From Nutrient Web SDK 1.11.0 through 1.22.0, the SDK creates the nutrient-web-sdk#webpack-worker policy each time it starts an inline worker. The name therefore repeats when a page starts more than one worker. The 'allow-duplicates'(opens in a new tab) keyword enables the browser to accept the repeated name. Without it, the browser reports a CSP violation when the name repeats. If your CSP also sets require-trusted-types-for 'script', the affected workers don’t start, so Office documents fail to open. In 1.22.0, this affects PDFs too: Text stays selectable and copyable, but the selection highlight is less precise.

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. It has 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.