This HTML page is not optimized for LLM or AI agent consumption. Fetch the Markdown version instead: /guides/document-authoring/deploy-and-production/content-security-policy-and-firewall-rules.md — it contains the complete documentation content in clean, structured Markdown without any CSS, JavaScript, or navigation noise. CSP and firewall rules for document authoring

Enhancing document authoring with CSP guidelines

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

This guide may apply to you if you aren’t self-hosting assets. By default, we load most assets from our content delivery network (CDN). Self-hosting is a great choice for those who want either more control or offline-first capabilities.

Content Security Policy (CSP) headers are an essential security feature designed to help protect web applications from various types of attacks, such as cross-site scripting (XSS) and data injection attacks. CSP allows you to specify the sources from which the browser is permitted to load resources — such as scripts, styles, and images — thereby reducing the risk of malicious code execution.

For more detailed information on CSP, refer to the MDN Web Docs on CSP(opens in a new tab).

Use a strict CSPv3 policy with a per-request nonce and the strict-dynamic directive. This enables your application to trust the scripts it explicitly marks with a nonce, while scripts loaded by those trusted scripts can run without maintaining a brittle host allowlist. Refer to the web.dev article(opens in a new tab) for more details:

Content-Security-Policy:
  script-src 'nonce-{random}' 'unsafe-inline' 'unsafe-eval' 'strict-dynamic' https: http:;
  object-src 'none';
  base-uri 'self';

Generate a new cryptographically random nonce for every response, add it to the CSP header, and apply the same value to the trusted <script> tags that bootstrap your application and Document Authoring. Nonces are unique values that are generated for each request, enabling you to identify which scripts are trusted. Learn more about using nonces in this tutorial on CSP(opens in a new tab).

With strict-dynamic, modern browsers ignore the host sources in script-src once a valid nonce is present. The https: and http: sources remain in the example only as compatibility fallbacks for browsers that don’t support strict-dynamic.

Using CSP via a meta tag

Setting CSP as an HTTP response header is recommended. For local testing, or when server-side header management isn’t possible, you can also specify CSP directives directly in your HTML using a <meta> tag. As with the HTTP header approach, the nonce value in the meta tag must match the nonce on your trusted script tags:

<meta
  http-equiv="Content-Security-Policy"
  content="script-src 'nonce-{random}' 'unsafe-inline' 'unsafe-eval' 'strict-dynamic' https: http:; object-src 'none'; base-uri 'self';"
/>

Firewall considerations

If you’re behind a firewall and you aren’t self-hosting assets, allow outbound connections to https://document-authoring.cdn.nutrient.io so Document Authoring can load CDN-hosted assets.

Other resources

By following these guidelines, you’ll ensure that all functionality works out of the box and adheres to good security practices. Remember to keep your CSP directives updated as your application evolves and to test your configuration thoroughly to avoid breaking functionality.

For more in-depth guidance on CSP, refer to the MDN Web Docs(opens in a new tab) and consider using tools like CSP Evaluator(opens in a new tab) to analyze and refine your policy.