Chrome请求Jenkins发布的CSS文件时不携带Session-Cookie问题

问题根本原因 #

Chrome 80+版本默认会将未显式声明SameSite属性的Cookie视为SameSite=Lax，而Jenkins返回的页面携带的sandbox CSP头默认没有配置allow-same-origin权限，浏览器会将沙箱页面加载的静态资源请求判定为跨站上下文，Lax模式下不会携带Cookie，最终导致CSS资源请求返回403。

解决方案 #

方案1：修改Jenkins启动参数配置SameSite属性（适用于内置Jetty启动场景） #

Jenkins 2.249及以上版本原生支持配置Session Cookie的SameSite属性，操作步骤如下：

• 找到Jenkins启动配置文件，不同系统默认路径如下：
  • Debian/Ubuntu系统：/etc/default/jenkins
  • CentOS/RHEL系统：/etc/sysconfig/jenkins
  • Windows系统：Jenkins安装目录下的jenkins.xml
  • Docker部署：直接修改启动命令的环境变量
• 在启动参数中添加--sessionCookieSameSite=None，如果是HTTPS部署的生产环境，必须同步添加--sessionCookieSecure=true（Chrome要求SameSite=None的Cookie必须同时开启Secure属性，否则配置会被忽略）。
  配置示例（Linux系统）：

JENKINS_ARGS="--webroot=/var/cache/jenkins/war --httpPort=8080 --sessionCookieSameSite=None --sessionCookieSecure=true"

配置示例（Docker启动）：

docker run -d -p 8080:8080 -e JENKINS_OPTS="--sessionCookieSameSite=None --sessionCookieSecure=true" jenkins/jenkins:lts

修改完成后重启Jenkins服务即可生效。

方案2：反向代理层修改Cookie属性（适用于Nginx/Apache反向代理场景） #

如果Jenkins前端挂了反向代理，可以直接在代理层修改Cookie的SameSite属性，无需修改Jenkins本身配置，Nginx配置示例如下：

# HTTPS部署场景
proxy_cookie_path / "/; SameSite=None; Secure";
# 内网HTTP测试场景可去掉Secure属性
# proxy_cookie_path / "/; SameSite=None";

修改后重载Nginx配置即可生效。

方案3：调整Jenkins CSP配置（仅推荐测试环境使用） #

如果不想修改Cookie属性，也可以调整Jenkins的CSP规则，给sandbox参数增加allow-same-origin权限，使沙箱页面上下文和Jenkins主站保持同源，静态资源请求就会正常携带Cookie：
修改后的CSP响应头示例：

Content-Security-Policy: sandbox allow-same-origin; default-src 'none'; img-src 'self'; style-src 'self';
X-Content-Security-Policy: sandbox allow-same-origin; default-src 'none'; img-src 'self'; style-src 'self';
X-WebKit-CSP: sandbox allow-same-origin; default-src 'none'; img-src 'self'; style-src 'self';

该配置可在Jenkins全局安全设置中的「Content Security Policy」项修改。

内容的提问来源于stack exchange，提问作者TomStroemer