Issue
Content Security Policy (CSP) is a security standard designed to prevent cross-site scripting (XSS) and other code injection attacks that can happen when malicious code is executed in the context of a trusted browser session. CSP was added to Jenkins LTS in version 1.625.3, and although it has been around for a long time now, it can still adversely impact certain plugins and other use cases. There are various ways to modify the Jenkins CSP settings to enable required workflows without compromising security.
Environment
-
CloudBees CI (CloudBees Core) on modern cloud platforms - Managed controller
-
CloudBees CI (CloudBees Core) on modern cloud platforms - Operations Center
-
CloudBees CI (CloudBees Core) on traditional platforms - Client controller
-
CloudBees CI (CloudBees Core) on traditional platforms - Operations Center
Context
As of Jenkins version 2.200 (LTS 2.204.1), Jenkins natively allows to serve resources from another domain. While modifying CSPs is still possible (and may be acceptable depending on your security context), we recommend having a look to How to Serve Resources from Jenkins before resorting to modifying the CSPs.
By default the Jenkins Content-Security-Policy header is set to a very restrictive set of permissions. This may cause issues with certain plugins, or with serving custom HTML from Jenkins, such as HTML reports generated by a build. When deciding whether to relax these permissions, it is important to consider a couple of things. First, are less-trusted users allowed to create or modify files in Jenkins workspaces? This doesn’t just include users with access to the Jenkins controller and agent hosts - any code in an SCM repo that is built by Jenkins will be stored in the workspace. If Jenkins is building pull requests sent by unknown or untrusted users, for example, this would be a concern. Second, are there any less-trusted agents connected to Jenkins? In most environments the Jenkins administrators tightly control the pool of agents connected to a controller, but in other cases users are allowed to "bring their own" agents. If these agents cannot be vetted before they are connected to the controller, any files stored in a build directory on them could potentially be unsafe.
If you feel that these concerns do not apply in your environment, and the strict CSP setting is causing problems for you, you can consider relaxing the permissions.
The following plugins are known to be affected by the strict CSP settings: Maven Integration, Javadoc, HTML Publisher, Gatling, and OWASP Dependency-Check. In addition, reports generated by build/test tools like PHPUnit, simplecov, rubycritic, etc. are known to be affected.
Resolution
To permanently change the CSP header used by Jenkins, you will need to set the -Dhudson.model.DirectoryBrowserSupport.CSP Java option when Jenkins is started. This article explains how to add Java options to the Jenkins service. However, you can also change the header on the fly using the Jenkins Script Console. This will allow you to test various changes to make sure that they address your use case, without the need for repeated restarts. Once you have found something that works, you can apply it permanently by using the Java option.
Some tips for setting the CSP header using the script console:
-
System.setProperty("hudson.model.DirectoryBrowserSupport.CSP", "")will unset the header, disabling the CSP feature completely. This is the most unsafe option, and not recommended, but you can use this to quickly check whether CSP is causing a problem. If you disable the header and your problem persists, it is not being caused by CSP. -
System.clearProperty("hudson.model.DirectoryBrowserSupport.CSP")will set the header back to the default, strict settings. -
System.getProperty("hudson.model.DirectoryBrowserSupport.CSP")will return the current value of the header.
For further information about how CSP impacts Jenkins, including workarounds for certain plugins, check the Jenkins wiki doc about CSP.