[JENKINS-41891] Serve static files from second domain as an alternative to setting CSP

[jenkins-infra-bot]

Dealing with Content-Security-Policy is just too annoying, and there's too many plugins trying to just serve static files in Jenkins, often for no real reason.

We need second domain support for static resources (DirectoryBrowserSupport) such that accessing that is possible without authentication, just with a token, and that token is used for linked resources as well.

---

Originally reported by danielbeck, imported from: Serve static files from second domain as an alternative to setting CSP

• assignee: danielbeck
• status: Closed
• priority: Major
• component(s): core
• label(s): security
• resolution: Fixed
• resolved: 2019-10-17T06:58:27+00:00
• votes: 2
• watchers: 8
• imported: 2025-11-24

Raw content of original issue

Dealing with Content-Security-Policy is just too annoying, and there's too many plugins trying to just serve static files in Jenkins, often for no real reason.

We need second domain support for static resources (DirectoryBrowserSupport) such that accessing that is possible without authentication, just with a token, and that token is used for linked resources as well.

[jenkins-infra-bot]

• Remote links associated with this issue:

  • CloudBees-internal issue
  • PR 4239

[jenkins-infra-bot]

jvz:

• Original comment link
• Raw content of original comment:

  Now when you say second domain, can you clarify on the expected scope here? Here are some potential scope options:
  
  
  	
  Support multiple domains via multiple web apps (i.e., keep Jenkins as one war, and have another war for handling static assets and access control)
  	
  Support multiple domains via fancy Apache configs
  	
  Support multiple domains where the static domain uses a dedicated web server like Apache or nginx (along with any config needed to allow for access control)
  	
  Support multiple domains via CDN
  
  
  
  Another orthogonal concern: using subdomains of the same domain versus completely separate domains (though since many static assets require authorization, the usual benefits of splitting up your CDN domain name from your app domain name don't apply; we still need the cookies).
  

Now when you say second domain, can you clarify on the expected scope here? Here are some potential scope options:

• Support multiple domains via multiple web apps (i.e., keep Jenkins as one war, and have another war for handling static assets and access control)
• Support multiple domains via fancy Apache configs
• Support multiple domains where the static domain uses a dedicated web server like Apache or nginx (along with any config needed to allow for access control)
• Support multiple domains via CDN

Another orthogonal concern: using subdomains of the same domain versus completely separate domains (though since many static assets require authorization, the usual benefits of splitting up your CDN domain name from your app domain name don't apply; we still need the cookies).

[jenkins-infra-bot]

jvz:

• Original comment link
• Raw content of original comment:

  Oh, I suppose maybe there's a fifth option:
  
  
  	
  VirtualHost-style support in Winstone. Avoids the need for a reverse proxy to combine domains in simple scenarios as well as duplicating the servlet container. I'm not sure if this is viable depending on Winstone/Jetty features.
  
  
  

Oh, I suppose maybe there's a fifth option:

• VirtualHost-style support in Winstone. Avoids the need for a reverse proxy to combine domains in simple scenarios as well as duplicating the servlet container. I'm not sure if this is viable depending on Winstone/Jetty features.

[jenkins-infra-bot]

jvz:

• Original comment link
• Raw content of original comment:

  Another option: when using Kubernetes, this is just an exercise in devops to rewrite ingress rules based on paths.
  

Another option: when using Kubernetes, this is just an exercise in devops to rewrite ingress rules based on paths.

[jenkins-infra-bot]

danielbeck:

• Original comment link
• Raw content of original comment:

  This is specifically about the functionality in DirectoryBrowserSupport that is affected by CSP from SECURITY-95 and breaks many plugins that follow the (anti)pattern of archiving a bunch of HTML files, then serving them via DirectoryBrowserSupport. We even had plugins programmatically disable CSP protection (SECURITY-309).
  
  Ideally we figure out a way for Jenkins/Stapler to respond differently for a different domain ( Host header) and implement something like github.com/githubusercontent.com on that domain.
  
  Ideally one DirectoryBrowserSupport would correspond to one random prefix (necessary since there would be no auth on the second domain to hijack), to not break relative links within a set of archived files, such as an archived set of Javadoc HTML files.
  

This is specifically about the functionality in DirectoryBrowserSupport that is affected by CSP from SECURITY-95 and breaks many plugins that follow the (anti)pattern of archiving a bunch of HTML files, then serving them via DirectoryBrowserSupport. We even had plugins programmatically disable CSP protection (SECURITY-309).

Ideally we figure out a way for Jenkins/Stapler to respond differently for a different domain ( Host header) and implement something like github.com/githubusercontent.com on that domain.

Ideally one DirectoryBrowserSupport would correspond to one random prefix (necessary since there would be no auth on the second domain to hijack), to not break relative links within a set of archived files, such as an archived set of Javadoc HTML files.

[jenkins-infra-bot]

jglick:

• Original comment link
• Raw content of original comment:

  a way for Jenkins/Stapler to respond differently for a different domain (Host header)
  
  No deep surgery in Stapler is really necessary, I think. Would suffice for Jenkins to define an UnprotectedRootAction to serve the static content. Then you can configure your reverse proxy to map requests to the special domain to a path prefix of the Jenkins service. For example, this is straightforward to set up in Kubernetes using the nginx-ingress controller.
  
  As to handling non-anonymously-readable content, this can be handled in various ways. Probably something like BoundObjectTable with a one-hour expiry would suffice. (To save memory and allow links to be valid indefinitely so long as the user exists and retains access, perhaps you could support WithWellKnownURL, by encoding both a path from root to the DirectoryBrowserSupport.owner (via JENKINS-26091) and an Authentication.name in a Secret. Given a random initialization vector, I believe that is safe.)
  
  The critical question for me is what constraints are placed on the “second domain” by the non-CSP defenses built into browsers. This very much affects whether administrators will find it practical to set up such a route: the reverse proxy is just a matter of configuration, but getting a new or expanded DNS entry typically requires extra steps. For example, if Jenkins is normally served from https://dev.mycorp.com/jenkins/ then which of the following URL prefixes would be eligible for serving static content?
  
  
  	
  https://dev.mycorp.com/static-jenkins/
  	
  https://static.dev.mycorp.com/
  	
  https://static-dev.mycorp.com/
  	
  https://mycorp-static.com/
  	
  https://static.mycorp.net/
  
  
  

a way for Jenkins/Stapler to respond differently for a different domain (Host header)

No deep surgery in Stapler is really necessary, I think. Would suffice for Jenkins to define an UnprotectedRootAction to serve the static content. Then you can configure your reverse proxy to map requests to the special domain to a path prefix of the Jenkins service. For example, this is straightforward to set up in Kubernetes using the nginx-ingress controller.

As to handling non-anonymously-readable content, this can be handled in various ways. Probably something like BoundObjectTable with a one-hour expiry would suffice. (To save memory and allow links to be valid indefinitely so long as the user exists and retains access, perhaps you could support WithWellKnownURL, by encoding both a path from root to the DirectoryBrowserSupport.owner (via JENKINS-26091) and an Authentication.name in a Secret. Given a random initialization vector, I believe that is safe.)

The critical question for me is what constraints are placed on the “second domain” by the non-CSP defenses built into browsers. This very much affects whether administrators will find it practical to set up such a route: the reverse proxy is just a matter of configuration, but getting a new or expanded DNS entry typically requires extra steps. For example, if Jenkins is normally served from https://dev.mycorp.com/jenkins/ then which of the following URL prefixes would be eligible for serving static content?

• https://dev.mycorp.com/static-jenkins/
• https://static.dev.mycorp.com/
• https://static-dev.mycorp.com/
• https://mycorp-static.com/
• https://static.mycorp.net/

[jenkins-infra-bot]

kon:

• Original comment link
• Raw content of original comment:

  The frame-ancestors directive of Content-Security-Policy cannot distinguish between https://dev.mycorp.com/jenkins/ and https://dev.mycorp.com/static-jenkins/. See CSP: frame-ancestors should check origins, not URLs · Issue #311 · w3c/webappsec.
  
  The HTTP cookies set by Jenkins seem to be using HostOnly and HttpOnly, except the "screenResolution" cookie. I think this makes https://static.dev.mycorp.com/ and https://static-dev.mycorp.com/ less risky than they might otherwise be.
  

The frame-ancestors directive of Content-Security-Policy cannot distinguish between https://dev.mycorp.com/jenkins/ and https://dev.mycorp.com/static-jenkins/. See CSP: frame-ancestors should check origins, not URLs · Issue #311 · w3c/webappsec.

The HTTP cookies set by Jenkins seem to be using HostOnly and HttpOnly, except the "screenResolution" cookie. I think this makes https://static.dev.mycorp.com/ and https://static-dev.mycorp.com/ less risky than they might otherwise be.

[jenkins-infra-bot]

jvz:

• Original comment link
• Raw content of original comment:

  I've read through some of the older issues related to this. So it seems like the main purpose of this feature request is to allow for the following scenario:
  
  As a plugin developer, I want a safe place to publish static assets on a separate domain so that a content security policy can be used to help prevent published content from interacting with and exploiting Jenkins itself. For example, if I wanted to publish some test results that have a fancy JavaScript-based UI, it would be nice to host that on its own domain so that it can't interact with Jenkins JavaScript files or similar. This would also be useful to avoid a vector for exploiting XSS vulnerabilities in Jenkins.
  
  Based on how CSP works as kon mentions, we have to distinguish based on the domain name mostly, not the URL (other than the scheme and port). So I'd imagine we should try to support all the listed suggestions from jglick except for the subdirectory one.
  
  Any directory browser that requires authentication wouldn't really benefit from a separate domain name like example-cdn.com to example.com due to needing cookies for both. Static resources that are publicly available can benefit from a separate domain for CDN usage, though that seems a bit overkill for Jenkins (or maybe it isn't?).
  

I've read through some of the older issues related to this. So it seems like the main purpose of this feature request is to allow for the following scenario:

As a plugin developer, I want a safe place to publish static assets on a separate domain so that a content security policy can be used to help prevent published content from interacting with and exploiting Jenkins itself. For example, if I wanted to publish some test results that have a fancy JavaScript-based UI, it would be nice to host that on its own domain so that it can't interact with Jenkins JavaScript files or similar. This would also be useful to avoid a vector for exploiting XSS vulnerabilities in Jenkins.

Based on how CSP works as kon mentions, we have to distinguish based on the domain name mostly, not the URL (other than the scheme and port). So I'd imagine we should try to support all the listed suggestions from jglick except for the subdirectory one.

Any directory browser that requires authentication wouldn't really benefit from a separate domain name like example-cdn.com to example.com due to needing cookies for both. Static resources that are publicly available can benefit from a separate domain for CDN usage, though that seems a bit overkill for Jenkins (or maybe it isn't?).

[jenkins-infra-bot]

jglick:

• Original comment link
• Raw content of original comment:

  As a plugin developer, I want a safe place to publish static assets
  
  Well, yes, but also we want admins to stop recklessly disabling CSP because of the many things that inevitably break when it is enabled and for which Googling the error message gives you bad advice.
  
  I'd imagine we should try to support all the listed suggestions from Jesse Glick
  
  Maybe I should clarify: the list is in order from easiest to configure to hardest to configure (in general). So if it is seems that merely having a nonequal host suffices for protection, then https://static.dev.mycorp.com/ would be the most attractive option as it only requires that your DNS grant for Jenkins accepts wildcards, which it may already. The code in Jenkins need not care at all which host you choose, but we need to have a canonical recommendation for the reverse proxy that is likely to be implementable.
  
  Any directory browser that requires authentication
  
  See above. danielbeck and I are both assuming that the feature is fully usable when the DirectoryBrowserSupport.owner is accessible only to certain authenticated users, because the static “site” is serving content only from specially constructed URLs that encode sufficient credentials. See for example what GitHub does when showing a Raw link for a file in a private repository.
  

As a plugin developer, I want a safe place to publish static assets

Well, yes, but also we want admins to stop recklessly disabling CSP because of the many things that inevitably break when it is enabled and for which Googling the error message gives you bad advice.

I'd imagine we should try to support all the listed suggestions from Jesse Glick

Maybe I should clarify: the list is in order from easiest to configure to hardest to configure (in general). So if it is seems that merely having a nonequal host suffices for protection, then https://static.dev.mycorp.com/ would be the most attractive option as it only requires that your DNS grant for Jenkins accepts wildcards, which it may already. The code in Jenkins need not care at all which host you choose, but we need to have a canonical recommendation for the reverse proxy that is likely to be implementable.

Any directory browser that requires authentication

See above. danielbeck and I are both assuming that the feature is fully usable when the DirectoryBrowserSupport.owner is accessible only to certain authenticated users, because the static “site” is serving content only from specially constructed URLs that encode sufficient credentials. See for example what GitHub does when showing a Raw link for a file in a private repository.

[jenkins-infra-bot]

jvz:

• Original comment link
• Raw content of original comment:

  I had a talk with Jesse to further hash out this idea. At the moment, the idea will be to create some sort of time-bound cache for static asset tokens to URLs where DirectoryBrowserSupport can be configured to only serve requests at a specific origin while all other requests are served from the Jenkins URL. When a secondary static domain is configured, the servlet filter should deny all requests to static assets unless they go through the configured domain, and requests to non-DBS pages must go through the root origin (possibly derived from Jenkins root URL config, though this might need to be a separate setting).
  
  Then it's a matter of setting up DNS appropriately to serve two domains to the same Jenkins instance and configuring the static origin settings. For Kubernetes-based setups, we might be able to provide or suggest some nginx-controller routing rules to support this. I'll likely be developing this feature using Apache as a reverse proxy, though I'll take a look into the K8s approach as well if it's not too complicated.
  

I had a talk with Jesse to further hash out this idea. At the moment, the idea will be to create some sort of time-bound cache for static asset tokens to URLs where DirectoryBrowserSupport can be configured to only serve requests at a specific origin while all other requests are served from the Jenkins URL. When a secondary static domain is configured, the servlet filter should deny all requests to static assets unless they go through the configured domain, and requests to non-DBS pages must go through the root origin (possibly derived from Jenkins root URL config, though this might need to be a separate setting).

Then it's a matter of setting up DNS appropriately to serve two domains to the same Jenkins instance and configuring the static origin settings. For Kubernetes-based setups, we might be able to provide or suggest some nginx-controller routing rules to support this. I'll likely be developing this feature using Apache as a reverse proxy, though I'll take a look into the K8s approach as well if it's not too complicated.

[jenkins-infra-bot]

jvz:

• Original comment link
• Raw content of original comment:

  To clarify on the GitHub example, here's a sample Jenkins analogue:
  
  
  	
  Main site: https://jenkins.dev.example.com/
  	
  Original static content URL: https://jenkins.dev.example.com/userContent/foo/bar.zip
  	
  Tokenized secondary domain URL: https://jenkins-static.dev.example.com/userContent/foo/bar.zip?token=ABC123...
  
  
  

To clarify on the GitHub example, here's a sample Jenkins analogue:

• Main site: https://jenkins.dev.example.com/
• Original static content URL: https://jenkins.dev.example.com/userContent/foo/bar.zip
• Tokenized secondary domain URL: https://jenkins-static.dev.example.com/userContent/foo/bar.zip?token=ABC123...

[jenkins-infra-bot]

danielbeck:

• Original comment link
• Raw content of original comment:

  I would expect the same model (token query parameter) to not work as soon as you render HTML files that include resources like images or external style sheets, unless you start rewriting responses, checking referrers, or similar.
  

I would expect the same model (token query parameter) to not work as soon as you render HTML files that include resources like images or external style sheets, unless you start rewriting responses, checking referrers, or similar.

[jenkins-infra-bot]

jglick:

• Original comment link
• Raw content of original comment:

  And that URL pattern would not work for UnprotectedRootAction anyway. I would expect something more along the lines of https://jenkins-static.dev.example.com/staticContent/ABC123/foo/bar.zip. Or for a more realistic transformation:
  
  
  	
  https://dev.example.com/jenkins/job/stuff/javadoc/com/corp/stuff/package-summary.html (default)
  	
  https://static.dev.example.com/jenkins/user-static-whatever/ABC123/com/corp/stuff/package-summary.html (with config set to static.dev.example.com)
  
  
  
  Here job/stuff/javadoc/ produces a DirectoryBrowserSupport in Stapler navigation, it gets bound to a table and assigned an ID, and then static content under that is served if the token matches.
  

And that URL pattern would not work for UnprotectedRootAction anyway. I would expect something more along the lines of https://jenkins-static.dev.example.com/staticContent/ABC123/foo/bar.zip. Or for a more realistic transformation:

• https://dev.example.com/jenkins/job/stuff/javadoc/com/corp/stuff/package-summary.html (default)
• https://static.dev.example.com/jenkins/user-static-whatever/ABC123/com/corp/stuff/package-summary.html (with config set to static.dev.example.com)

Here job/stuff/javadoc/ produces a DirectoryBrowserSupport in Stapler navigation, it gets bound to a table and assigned an ID, and then static content under that is served if the token matches.

[jenkins-infra-bot]

danielbeck:

• Original comment link
• Raw content of original comment:

  user-static-whatever would be the unprotected root action (since we're not changing the prefixes, just what subset of Jenkins gets served on each domain), and ABC123 the magic secret token.
  
  With https://static.dev.example.com/jenkins/user-static-whatever/ABC123 optionally redirecting to https://dev.example.com/jenkins/job/stuff/javadoc we have some convenient navigation between domains; alternatively, add an extra level for URLs like https://static.dev.example.com/jenkins/user-static-whatever/ABC123/root/com/corp/stuff/package-summary.html so that relative uplink to the job (or, more generally, Actionable, could work.
  

user-static-whatever would be the unprotected root action (since we're not changing the prefixes, just what subset of Jenkins gets served on each domain), and ABC123 the magic secret token.

With https://static.dev.example.com/jenkins/user-static-whatever/ABC123 optionally redirecting to https://dev.example.com/jenkins/job/stuff/javadoc we have some convenient navigation between domains; alternatively, add an extra level for URLs like https://static.dev.example.com/jenkins/user-static-whatever/ABC123/root/com/corp/stuff/package-summary.html so that relative uplink to the job (or, more generally, Actionable, could work.

[jenkins-infra-bot]

jvz:

• Original comment link
• Raw content of original comment:

  I have a general idea about how to manage the tokens for this. Are you suggesting the token should be in the path instead of as a query parameter?
  

I have a general idea about how to manage the tokens for this. Are you suggesting the token should be in the path instead of as a query parameter?