Content security policy is great for security perspective but causes a few issues that needs manually tweaks to the default rule (T215115, T245658).

I once hinted at using wmfusercontent.org to serve the artifact (T215115#4926869). Turns out Jenkins Upstream has implemented the feature! https://issues.jenkins-ci.org/browse/JENKINS-41891 It has been released with 2.204.1:

Add an option for a Resource Root URL through which Jenkins will serve user-generated static resources like workspace files or archived artifacts without the need for Content-Security-Policy headers.

It can be enabled at https://integration.wikimedia.org/ci/configure under Serve resource files from another domain > /Resource root URL. And here is the inline help:

Jenkins serves many files that are potentially created by untrusted users, such as files in project workspaces or archived artifacts. When no resource root URL is defined, Jenkins will serve these files with the HTTP header Content-Security-Policy ("CSP"). By default it is set to a value that disables many modern web features to prevent cross-site scripting (XSS) and other attacks on Jenkins users accessing these files. While the specific value for the CSP header is user configurable (and can even be disabled), doing so is a trade-off between security and functionality.

If the resource root URL is defined, Jenkins will instead redirect requests for user-created resource files to URLs starting with the URL configured here. These URLs will not set the CSP header, allowing Javascript and similar features to work. For this option to work as expected, the following constraints and considerations apply:

• The resource root URL must be a valid alternative choice for the Jenkins root URL for requests to be processed correctly.
  • The Jenkins root URL must be set and it must be different from this resource root URL (in fact, a different host name is required).
  • Once set, Jenkins will only serve resource URL requests via the resource root URL. All other requests will get HTTP 404 Not Found responses.

Once this URL has been set up correctly, Jenkins will redirect requests to workspaces, archived artifacts, and similar collections of usually user-generated content to URLs starting with the resource root URL. Instead of a path like job/name_here/ws, resource URLs will contain a token encoding that path, the user for which the URL was created, and when it was created. These resource URLs access static files as if the user for which they were created would access them: If the user’s permission to access these files is removed, the corresponding resource URLs will not work anymore either. These URLs are accessible to anyone without authentication until they expire, so sharing these URLs is akin to sharing the files directly.

Security considerations

Authentication

Resource URLs do not require authentication (users will not have a valid session for the resource root URL). Sharing a resource URL with another user, even one lacking Overall/Read permission for Jenkins, will grant that user access to these files until the URLs expire.

Expiration

Resource URLs expire after 30 minutes by default. Expired resource URLs will redirect users to their equivalent Jenkins URLs, so that the user can reauthenticate, if necessary, and then be redirected back to a new resource URL that will be valid for another 30 minutes. This will generally be transparent to the user if they have a valid Jenkins session. Otherwise, they will need to authenticate with Jenkins again. However, when browsing pages with HTML frames, like Javadoc sites, the login form cannot appear in a frame. In these cases, users will need to reload the top-level frame to make the login form appear.

To change how quickly resource URLs expire, set the system property jenkins.security.ResourceDomainRootAction.validForMinutes to the desired value in minutes. Earlier expiration might make it harder to use these URLs, while later expiration increases the likelihood of unauthorized users gaining access through URLs shared with them by authorized users.
Authenticity

Resource URLs encode the URL, the user for which they were created, and their creation timestamp. Additionally, this string contains an HMAC to ensure the authenticity of the URL. This prevents attackers from forging URLs that would grant them access to resource files as if they were another user.