crossorigin="anonymous" 时浏览器绝不会发送 Cookie、HTTP 认证头或 TLS 客户端证书，这是 W3C 规范强制要求；如需凭证，必须用 crossorigin="use-credentials" 并配合服务端精确的 Access-Control-Allow-Origin 和 Access-Control-Allow-Credentials: true 响应头。
script 标签的 crossorigin 不支持凭证传递
直接说结论：crossorigin="anonymous" 时，浏览器**绝不会发送 Cookie、HTTP 认证头或 TLS 客户端证书**。这是规范强制行为，不是配置疏漏，也不存在“安全传递凭证”的做法。
为什么 crossorigin="anonymous" 明确禁止凭证
W3C 规范定义：anonymous 表示“发起一个不带凭据的跨域请求”，即等价于 fetch 的 credentials: "omit"。浏览器会主动剥离所有可能泄露用户身份的信息，包括：
-
Cookie头（即使目标域名下存在匹配的 Cookie） -
Authorization头 -
Proxy-Authorization头 - 客户端 TLS 证书（如有）
这不是 bug，而是安全前提——否则第三方脚本可通过 <script crossorigin="anonymous"> 悄悄携带用户登录态，造成严重信息泄露。
想传凭证？只能用 crossorigin="use-credentials"
若你确实需要跨域加载脚本并附带凭证（例如：内部 CDN 上受登录态保护的 JS 包），必须同时满足三项条件：
立即学习“前端免费学习笔记（深入）”；
- HTML 中写成
<script src="https://cdn.example.com/app.js" crossorigin="use-credentials"></script> - 目标服务器响应头中必须包含
Access-Control-Allow-Origin（不能是*，必须是精确匹配的源，如https://your-site.com） - 服务器还必须显式设置
Access-Control-Allow-Credentials: true
缺任一条件，浏览器都会拒绝执行该脚本，并在控制台报错：Failed to load resource: Origin https://your-site.com is not allowed by Access-Control-Allow-Origin.
更现实的替代方案：避免在 script 加载阶段依赖凭证
绝大多数场景下，强行让 <script> 带凭证既危险又难维护。推荐拆解逻辑：
- 把需鉴权的业务逻辑放到运行时（比如用
fetch+credentials: "include"调用 API），而非打包进初始脚本 - 将受保护的 JS 拆为两部分：无状态的通用库（用
crossorigin="anonymous"加载），和含用户上下文的模块（通过动态import()+ 带凭证的 fetch 加载） - 后端改用 token 或 short-lived URL 签名代替 Cookie 鉴权，这样静态资源可公开访问，无需 CORS 凭证协商
真正容易被忽略的是：哪怕你写了 crossorigin="use-credentials"，只要服务端返回了 Access-Control-Allow-Origin: *，整个请求就立刻失效——浏览器会直接丢弃响应，连解析 JS 的机会都不给。
