CSP Headers

Content Security Policy (CSP) is a security mechanism that helps protect web applications from attacks such as Cross-Site Scripting (XSS) and other code injection threats. CSP allows administrators to define which resources—such as scripts, styles, and images—can be loaded and executed on a page. By enforcing CSP, the platform reduces the risk of malicious code compromising the application.

Configuration Location

CSP settings can be configured in the platform under the Configuration section, specifically in the Security tab. This section contains all available security headers.

Path:

.../administration/configuration/security

Setting CSP Headers

Detailed explanations and examples of configuring individual CSP headers can be found in the Helmet npm package documentation.

To configure CSP in the platform, insert the contentSecurityPolicy object into the configuration as JSON. Ensure the JSON structure is valid by adding double quotes around keys and values and removing any extra commas.

Example Configuration

Basic CSP Configuration

{
    "directives": {
        "script-src": ["'self'", "example.com"],
        "style-src": null
    }
}

Default CSP Configuration in Team assistant

//csp.contentSecurityPolicy
{
    "directives": {
        "default-src": ["'self'"],
        "script-src": ["'self'"],
        "style-src": ["'self'"],
        "img-src": ["'self'"],
        "font-src": ["'self'"],
        "connect-src": ["'self'"],
        "frame-ancestors": ["'self'"],
        "base-uri": ["'self'"],
        "form-action": ["'self'"],
        "object-src": ["'none'"],
        "media-src": ["'self'"],
        "worker-src": ["'self'"],
        "child-src": ["'self'"],
        "manifest-src": ["'self'"]
    }
}

//csp.crossOriginEmbedderPolicy

{"Cross-Origin-Embedder-Policy": "require-corp"}

//csp.crossOriginOpenerPolicy
{ "Cross-Origin-Opener-Policy": "same-origin"}

// csp.crossOriginResourcePolicy
{"Cross-Origin-Resource-Policy": "same-origin"}

//csp.originAgentCluster
true

//csp.referrerPolicy
{ "Referrer-Policy": "no-referrer-when-downgrade"}

//csp.strictTransportSecurity
{ "Strict-Transport-Security": {
            "max-age": 31536000,
            "includeSubDomains": true,
            "preload": true
        }}

//csp.xContentTypeOptions
true

//csp.xDnsPrefetchControl
{"X-DNS-Prefetch-Control": "off"}

//csp.xDownloadOptions
true

//csp.xFrameOptions
{    "X-Frame-Options": "DENY"}

//csp.xPermittedCrossDomainPolicies
{"X-Permitted-Cross-Domain-Policies": "none"}

//csp.xPoweredBy
true

//csp.xXssProtection
true

Best Practices

1. Test in a Development Environment – Before applying CSP policies in production, test them in a development or staging environment to avoid locking users out.
2. Use a CSP Report-Only Mode First – Before enforcing strict policies, use CSP's report-only mode to gather potential issues without blocking content.
3. Gradually Increase Restrictions – Start with a basic policy and gradually tighten restrictions as you identify necessary exceptions.
4. Regularly Review CSP Reports – Monitor reports for blocked resources and adjust policies accordingly.

By correctly configuring CSP in the platform, administrators can significantly enhance security and minimize risks associated with malicious code execution.