Jump to content

Connect SuperML | Leeroopedia MCP: Equip your AI agents with best practices, code verification, and debugging knowledge. Powered by Leeroo — building Organizational Superintelligence. Contact us at founders@leeroo.com.

Principle:Langgenius Dify CSP Policy

From Leeroopedia
Knowledge Sources Dify
Domains Frontend, Security
Last Updated 2026-02-12 07:00 GMT

Overview

Content Security Policy enforcement with nonce-based script protection and configurable domain whitelists, preventing cross-site scripting and unauthorized resource loading.

Description

The CSP Policy principle defines how Dify protects its frontend against cross-site scripting (XSS) attacks and unauthorized resource injection through HTTP Content Security Policy headers. The implementation uses nonce-based script allowlisting, where each page load generates a unique cryptographic nonce that must be present on script tags for the browser to execute them. This approach is more secure than hash-based or domain-based allowlisting because it prevents replay attacks and does not require maintaining a static list of allowed script hashes.

In the Dify codebase, CSP enforcement is implemented within the security middleware layer. The middleware generates a per-request nonce, injects it into the CSP header, and makes it available to the rendering pipeline for inclusion in script tags. Domain whitelists are configurable through environment variables, allowing operators to add trusted external domains for resources like analytics scripts, CDN-hosted assets, or third-party integrations without modifying the application code.

This principle matters because Dify handles sensitive data including API keys, model configurations, and potentially proprietary training data. A successful XSS attack could exfiltrate this data or manipulate workflows. The nonce-based CSP provides defense-in-depth beyond input sanitization, ensuring that even if an attacker manages to inject HTML, the browser will refuse to execute unauthorized scripts. The configurable whitelist approach balances security with operational flexibility, allowing each deployment to tailor the policy to its specific integration requirements.

Usage

Use this principle when:

  • Adding new script sources or external resource dependencies to the frontend
  • Configuring CSP headers for specific deployment environments with custom integrations
  • Debugging blocked resources in the browser console related to CSP violations

Theoretical Basis

Content Security Policy is a W3C standard that provides a declarative mechanism for controlling which resources a browser is allowed to load for a given page. The nonce-based approach follows CSP Level 3 specifications, which introduced the 'strict-dynamic' directive and nonce propagation for trusted script chains. This aligns with the defense-in-depth security principle, adding a browser-enforced layer that operates independently of server-side input validation and output encoding.

Related Pages

Page Connections

Double-click a node to navigate. Hold to expand connections.
Principle
Implementation
Heuristic
Environment