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, Team assistant reduces the risk of malicious code compromising the application.

Configuration Location

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

Path:

.../administration/configuration/security

Warning: Incorrect settings can lock the entire TAS. Ideally, configure only if you have access to the database so that any lock on TAS can be remedied. In the DB, this pertains to the CONFIG table and VAR_NAME security.csp.[name]

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 Team assistant, 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 Team assistant, administrators can significantly enhance security and minimize risks associated with malicious code execution.

Anna Gernát Updated by Anna Gernát

Sequences

Logs

Contact

Syca (opens in a new tab)

Powered by HelpDocs (opens in a new tab)