Plugins need to be careful when presenting user-generated content on the Jenkins UI. This usually takes one of two forms:
The plugin archives a report of some kind that was generated during the build and makes it available on the Jenkins UI.
The plugin parses a data file of some kind, usually as a post-build step, and presents the contents to the user, e.g. through the use of a
To circumvent this, Jenkins by default serves archived artifacts, including HTML reports, as well as workspace contents using Content-Security-Policy headers when using the
This protection must not be circumvented by plugins.
If reports look broken due to these restrictions, Jenkins administrators should set up a Resource Root URL from which Jenkins would service user content like archived artifacts without compromising security.
Plugins that directly show report information on the Jenkins UI without going through
DirectoryBrowserSupport need to be careful to not render potentially unsafe content unescaped.
Util#xmlEscape is a good way to escape content.
Otherwise, a dependency on a library such as OWASP/java-html-sanitizer could be used to sanitize HTML and only allow a known subset.
The advice on Preventing Cross-Site Scripting in Jelly views may apply here too, depending on implementation.