CSP Header Contains 'unsafe-eval' and 'unsafe-inline' - Security Hardening Options?

Technical assistance
1

Used Zammad version: 6.5.2-1767354399.5ee205d5

Used Zammad installation type: package (DEB package on Ubuntu)

Operating system: Ubuntu 24.04 LTS (Noble)

Browser + version: N/A (Server-side CSP configuration issue)

Context:

During a security audit of our Zammad instance, we identified that the Content Security Policy (CSP) header includes two directives that are flagged as security concerns by our security scanning tools:

  • 'unsafe-eval' in the script-src directive
  • 'unsafe-inline' in the style-src directive

Current CSP header (example from our instance):

base-uri 'self'; 
default-src 'self' ws: wss:; 
font-src 'self' data:; 
img-src * data: blob:; 
object-src 'none'; 
script-src 'self' 'unsafe-eval' 'nonce-[...]'; 
style-src 'self' 'unsafe-inline'; 
frame-src www.youtube.com player.vimeo.com

We located the CSP configuration file at: /opt/zammad/config/initializers/content_security_policy.rb

Expected behavior:

We would like to harden the CSP configuration by removing or replacing the 'unsafe-eval' and 'unsafe-inline' directives while maintaining full Zammad functionality.

Actual behavior:

The current CSP configuration includes these “unsafe” directives, which:

  • Increase the attack surface for potential XSS (Cross-Site Scripting) attacks
  • Are flagged by security scanning tools as vulnerabilities
  • May not align with strict security compliance requirements (SOC 2, ISO 27001, etc.)

Questions:

  1. Is there a roadmap or plan to remove these 'unsafe-*' directives from Zammad’s default CSP?
  • We understand this may require significant code refactoring
  1. Are these directives essential for Zammad’s core functionality?
  • If yes, which specific features depend on them?
  • Would disabling/restricting them break any critical features?
  1. Has anyone successfully hardened the CSP on their Zammad instance?
  • What approach did you take?
  • Did it require code modifications?
  • Any documented workarounds?
  1. Is it safe to modify /opt/zammad/config/initializers/content_security_policy.rb directly?
  • Would our changes be overwritten during package updates?
  • Is there a recommended way to override CSP settings?
  1. Would manually overriding the CSP header at the reverse proxy level (nginx/Apache) be viable?
  • Or would this likely break Zammad’s JavaScript/CSS functionality?

Additional Context:

We understand that:

  • Refactoring code to remove eval() usage is complex
  • Moving inline scripts/styles to external files requires significant development effort
  • These changes could potentially introduce regressions

We’re trying to assess whether this is:

  • A known architectural limitation of Zammad’s current design
  • Something being addressed in future releases
  • Something that requires a custom fork or patch

Any guidance from the Zammad team or community experiences would be greatly appreciated! We’re happy to contribute back any solutions we develop or test proposed fixes.