Access-Control-Allow-Origin: https://app.example.com 配合 Access-Control-Allow-Credentials: true。来源回显 Origin、凭据显式允许,浏览器把响应交给脚本。
数据与服务 · 网络与接口
跨域资源共享CORS
CORS 是浏览器执行的来源许可协议。简单请求直接校验响应,复杂请求先用 OPTIONS 预检;方法、请求头、来源和凭据必须在同一份可验证契约中对齐。
把响应头交给浏览器判定
CORS 不是前端发一个开关就能打开的通道。挑一个请求场景,调整服务端的 Access-Control-* 回答,再运行浏览器判定——观察「请求已到达服务端」和「脚本可读取响应」并不是同一件事。
/api/weatherOrigin: https://app.example.comGET /api/weatherAccept: application/jsonAccess-Control-Allow-Origin: https://app.example.com脚本可读取?待判定GET 只带 safelisted 请求头;浏览器直接发送实际请求,再检查响应中的许可。
先选请求场景、调整服务端回答,再运行浏览器判定。
对照规则:浏览器拿 Origin 提问,服务端用 Access-Control-* 回答;预检要答方法和请求头,凭据要回显明确来源。任一项缺失,浏览器都不把响应交给脚本。
键盘:Tab 进入场景,←/→ 或 Home/End 切换;表单控件和判定按钮均可用 Enter/Space 操作。
CORS 是双向对照契约
浏览器带着 Origin 提问,服务端用 Access-Control-* 回答,最后仍由浏览器决定脚本能否读取响应。把这份契约的字段和方向记清楚,调试时就知道该看哪一行。
什么时候要管 CORS,怎么修
CORS 是浏览器执行的安全策略,不是前端能关闭的开关。先认出它,再到服务端写对响应头。
- 控制台报
No 'Access-Control-Allow-Origin'或blocked by CORS policy,但用 curl/Postman 发同一请求能通——这是浏览器在拦截跨来源响应,不是服务端挂了。 - 跨来源(协议、主机或端口任一不同)的 fetch、XHR、读取像素的
<img>、@font-face才受 CORS 约束;同源请求和「服务器到服务器」的调用不涉及。
- 服务端响应写
Access-Control-Allow-Origin:优先明确来源白名单,无凭据时才可用受控的*,并加Vary: Origin防缓存串用。 - 预检
OPTIONS要回答Access-Control-Allow-Methods与Access-Control-Allow-Headers,缺一项实际请求就不发。 - 带 Cookie 时回显明确 Origin 并加
Access-Control-Allow-Credentials: true;*与凭据不能混用。
前端无法「关闭」CORS——它是浏览器策略。要么改服务端响应头,要么让前端走同源代理。
同一凭据请求,改一处来源就反转结果
带 Cookie 的跨域请求最容易踩坑。把同一份 fetch 只改服务端 Allow-Origin 的写法,脚本能否读取响应就反转。
Access-Control-Allow-Origin: * 与 credentials: 'include' 搭配。通配来源不能与凭据混用,浏览器拒绝把响应交给脚本——即使服务端已处理请求。
快速自测
JSON POST 的 OPTIONS 响应漏掉 Access-Control-Allow-Headers: Content-Type 时,浏览器会怎样?
继续查证
术语的技术定义和行为以这些一手或权威资料为准。
下一步学
和本知识点经常一起出现的概念。