文档教程知识库【免费下载链接】til:memo: Today I Learned项目地址https://gitcode.com/gh_mirrors/ti/til点击查看免费下载跨域请求Cross-Origin Request在浏览器端默认不会携带 Cookie、Authorization 头或 TLS 客户端证书这是浏览器针对 XSS 攻击的一道默认防线。本指南基于 til 仓库中的 devops/allow-cross-origin-requests-to-include-cookies.md 展开讲解如何通过客户端fetch的credentials选项与服务端Access-Control-Allow-Credentials、Access-Control-Allow-Origin两个响应头协同配置让浏览器允许跨域请求携带凭据。读完你将掌握从「同源/跨源判定」到「前后端两端配置」的完整链路并能排查最常见的*通配符导致的凭据失效问题。跨域请求为什么默认不带凭据当客户端例如浏览器向服务器发起跨域fetch请求时浏览器会强制执行各类 CORS 保护。其中一项默认保护是不在请求中携带凭据credentials同时也不把凭据暴露给客户端的 JavaScript 代码。这里所说的凭据通常包括Cookie会话标识Authorization请求头如 Bearer Token、Basic AuthTLS 客户端证书从安全角度看这一默认行为是为了避免 XSS 攻击——如果浏览器无条件把用户的登录凭据附加到任意跨域请求上攻击者就能借注入到页面中的脚本把携带凭据的请求发往攻击者控制的服务器造成会话劫持。这一行为由 HTTP 响应头Access-Control-Allow-Credentials控制。先厘清「同源」与「跨源」要理解跨域请求的凭据策略首先需要明确什么算「跨源」。til 仓库中另有一篇 http/what-counts-as-cross-origin-with-cors.md 专门讲解了 origin 的构成一个 origin 由 URL 中的 schemeHTTP/HTTPS、host含子域名、port 三者共同定义。三者全部一致才算同源只要 scheme、host、port 任意一项不同就是跨源。常见的跨源场景示例取自该文档https://example.comvshttp://example.com—— scheme 不同https://example.comvshttps://sub.example.com—— host 不同https://example.com:3000vshttps://example.com:5000—— port 不同而 URL 中 origin 之后的 path 部分不参与同源判定。也就是说只有完整匹配 scheme host port 的请求才是同源请求才会被浏览器视为「可信」否则就落入 CORS 凭据保护的范围。客户端用 fetch 显式声明携带凭据默认情况下即使是同源请求浏览器也不会自动携带凭据之外的额外动作对于跨域请求更是默认不携带任何凭据。如果业务确实需要把 Cookie 等凭据随跨域请求一起发送客户端必须在发起fetch时显式声明fetch(url, { credentials: include })credentials是 Fetch API 的标准选项常见的取值有omit无论同源还是跨域都不携带凭据same-origin仅在同源请求中携带凭据这是许多浏览器与库的默认行为include同源与跨域请求都携带凭据跨域场景必须显式指定如上面的示例。需要注意客户端单方面声明是不够的。要让请求中的凭据真正被允许客户端请求与服务端响应必须双方「达成一致」——即服务端也必须同意接受凭据。服务端两个响应头缺一不可服务端需要做两件事且缺一不可1. 返回Access-Control-Allow-Credentials: true响应头中必须包含Access-Control-Allow-Credentials: true该响应头告诉浏览器本次响应允许携带凭据且允许客户端 JavaScript 读取与凭据相关的响应信息。若缺少该头浏览器会拒绝把凭据注入跨域请求并拦截响应前端表现为请求失败或拿不到数据。2.Access-Control-Allow-Origin必须精确指定来源这是最容易踩坑的一点Access-Control-Allow-Origin不能设置为*通配符而必须明确列出发起请求的那个客户端 origin即上节所说的 scheme host port 组合。Access-Control-Allow-Origin: https://app.example.com Access-Control-Allow-Credentials: true如果用Access-Control-Allow-Origin: *配合Access-Control-Allow-Credentials: true浏览器会直接判定配置非法CORS 规范禁止「通配符来源 携带凭据」的组合从而拒绝请求。原因很直接凭据与用户身份绑定服务端必须明确知道「我信任的是哪一个来源」通配符意味着对任意来源都开放凭据这与凭据保护的初衷相悖。3. 普通 GET 响应与预检请求响应都要覆盖服务端设置这两个响应头的场景有两类简单请求如 GET的直接响应浏览器在收到响应后会校验响应头中的 CORS 字段决定是否把凭据暴露给页面脚本预检请求Preflight的响应当跨域请求带有非简单请求特征如自定义请求头、非简单方法等时浏览器会先发送OPTIONS预检请求服务端需要在预检响应中也返回上述 CORS 响应头后续的真实请求才会被放行。因此无论是 GET 响应还是 preflight 响应服务端中间件都应统一附加这两个头避免「有的接口能带 Cookie、有的不能」的不一致现象。完整配置示例一段前后端闭环把两端配置拼在一起一个完整的「跨域带 Cookie」链路如下客户端浏览器中的 JavaScriptfetch(https://api.example.com/session, { credentials: include }) .then((res) res.json()) .then((data) console.log(data));服务端以响应头的方式呈现任意后端语言皆可实现HTTP/1.1 200 OK Access-Control-Allow-Origin: https://app.example.com Access-Control-Allow-Credentials: true Content-Type: application/json { user: alice, session: valid }只有当以上客户端与服务端配置同时满足时浏览器才会允许跨域请求携带 Cookie并让前端脚本读取响应内容。实战排查要点在本地开发或线上排障时可以按以下顺序核对客户端是否写了credentials: include跨域fetch默认不会带凭据忘了声明则请求里根本没有 Cookie服务端是否返回Access-Control-Allow-Credentials: true缺失该头浏览器直接拒绝携带凭据的跨域响应Access-Control-Allow-Origin是否为具体来源一旦出现*与凭据组合请求必然失败需要把来源精确到具体 origin预检响应是否同样配置若接口触发 preflightOPTIONS响应缺失 CORS 头同样会导致请求中断。值得一提的是til 仓库中另有一篇 react/proxy-to-an-api-server-in-development-with-cra.md介绍了开发环境下借助 CRA 的webpackDevServer代理将 API 请求转发到后端从而绕开 CORS 问题的思路。这是开发期规避跨域配置摩擦的常用手段但生产环境的直接跨域调用仍需按本指南完成服务端 CORS 头配置。小结要让跨域请求携带 Cookie 等凭据需要「前后端双边确认」客户端fetch(url, { credentials: include })显式声明携带凭据服务端响应头同时满足Access-Control-Allow-Credentials: true与Access-Control-Allow-Origin: 具体来源且来源不能是*覆盖范围普通 GET 响应与 preflight 预检响应均需带上上述响应头。理解并正确配置这一机制既能保住登录态跨域共享的业务能力又不破坏浏览器默认的 XSS 凭据防护底线。仓库中的 devops/allow-cross-origin-requests-to-include-cookies.md 与 http/what-counts-as-cross-origin-with-cors.md 可继续作为速查参考。赞分享文档教程知识库【免费下载链接】til:memo: Today I Learned项目地址https://gitcode.com/gh_mirrors/ti/til点击查看免费下载相关推荐hub api隐藏大招在Shell脚本中直接调用GitHub REST API的完整指南hub api隐藏大招在Shell脚本中直接调用GitHub REST API的完整指南 hub 是一款让 git 与 GitHub 配合更省心的命令行工具开发工具CLInode-fetch跨域资源共享Access-Control-Allow-Origin配置指南node fetch跨域资源共享Access Control Allow Origin配置指南 你是否在使用node fetch时遇到过Access to后端终极指南Next.js中间件CORS凭证配置轻松解决跨域请求携带Cookie难题终极指南Next.js中间件CORS凭证配置轻松解决跨域请求携带Cookie难题 Next.js作为React框架的佼佼者提供了强大的中间件功能让开发者前端后端Web框架SSR前端构建上一篇CasperJS分布式追踪OpenTelemetry集成与性能分析下一篇Three20手势识别iOS应用交互体验增强创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考