---
title: "Content Security Policy"
canonical_url: "https://www.nutrient.io/guides/web/troubleshooting/content-security-policy/"
md_url: "https://www.nutrient.io/guides/web/troubleshooting/content-security-policy.md"
last_updated: "2026-06-11T10:44:30.351Z"
description: "Content Security Policy directives required to run Nutrient Web SDK, for both standalone and Document Engine deployments."
---

Nutrient Web SDK requires a small set of [Content Security Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Security-Policy) (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](#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`](https://www.nutrient.io/api/web/NutrientViewer.Configuration.html#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`](https://www.nutrient.io/api/web/interfaces/Configuration.html#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](https://www.nutrient.io/guides/web/changelog.md) 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`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Security-Policy/script-src):

> 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](https://github.com/WebAssembly/content-security-policy/blob/main/proposals/CSP.md):

> `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](https://developer.mozilla.org/en-US/docs/WebAssembly/Concepts) 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](https://developer.mozilla.org/en-US/docs/Web/API/Trusted_Types_API):

```

trusted-types nutrient-web-sdk nutrient-web-sdk#webpack nutrient-web-sdk#webpack-worker;

```

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

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](https://developer.mozilla.org/en-US/docs/WebAssembly/Concepts) 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](https://www.w3.org/TR/CSP3/), it’s the standards-defined directive for permitting WebAssembly under a strict CSP.

## References

- [MDN Content-Security-Policy: script-src](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Security-Policy/script-src)

- [MDN Content-Security-Policy header](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Security-Policy)

- [MDN WebAssembly concepts](https://developer.mozilla.org/en-US/docs/WebAssembly/Concepts)

- [W3C CSP Level 3 specification](https://www.w3.org/TR/CSP3/)

- [WebAssembly CSP proposal](https://github.com/WebAssembly/content-security-policy/blob/main/proposals/CSP.md)
---

## Related pages

- [Bug Reporting](/guides/web/troubleshooting/bug-reporting.md)
- [Chunkloaderror During Pspdfkit To Nutrient Migration In Ember](/guides/web/troubleshooting/chunkloaderror-during-pspdfkit-to-nutrient-migration-in-ember.md)
- [Debug Logging](/guides/web/troubleshooting/debug-logging.md)
- [Fixing Symbol Iterator Error](/guides/web/troubleshooting/fixing-symbol-iterator-error.md)
- [Fixing Split Undefined Error With Npm Build](/guides/web/troubleshooting/fixing-split-undefined-error-with-npm-build.md)
- [This will make the current directory contents available through `http://0.0.0.0:5000`.](/guides/web/troubleshooting/common-issues.md)
- [Testing Troubleshooting](/guides/web/troubleshooting/testing-troubleshooting.md)
- [npm](/guides/web/troubleshooting/nightlies.md)
- [Typescript](/guides/web/troubleshooting/miscellaneous/typescript.md)
- [Webassembly Simd Support](/guides/web/troubleshooting/webassembly-simd-support.md)