CORS 由谁执行？
浏览器依据服务器返回的 CORS 策略决定是否向跨源脚本暴露响应。非浏览器客户端不因这套读取规则而自动失去访问能力。[1][2]
013 / Web 与应用 / CORS
请求发出去了，为什么读不到？
CORS · CORS
浏览器、服务器和页面脚本看到的不是同一件事。先区分请求有没有发出，再检查响应是否允许交给跨源脚本读取。
开始探索 ↓7–10 分钟
动手实验 · 场景判断 · 实用检查
动手实验 · 场景判断 · 实用检查
城门与不同船只比喻跨源读取策略。浏览器与服务端机器人受到的规则不同；画面不是一个能替代接口授权的网络防火墙。
展开读图提示
读图提示
- 角色与机制
- 城堡比喻服务端，船上的页面比喻不同来源，守卫比喻浏览器按响应中的 CORS 规则决定能否读取响应。
- 风险在哪里
- 错误地信任任意 Origin 并允许携带凭据，可能让恶意网页读取用户数据；桥下的小船提醒浏览器规则管不到所有客户端。
- 防护与边界
- 只允许明确可信的来源并谨慎开启凭据。CORS 不代替服务端认证、授权或 CSRF 防护，也不保证请求完全不会发出。
本课任务 / CORS
把预检、实际请求与响应可读性拆成三个独立判断。
- 观察简单请求与需要预检的请求
- 组合来源、凭据模式与响应头
- 解释 CORS 为什么不是服务端授权
亲手探索 / 不同条件，不同结果
从 OPTIONS 到 JavaScript，把每个阶段都看清。
切换请求类型、允许来源与凭据条件，比较实际请求是否发送、服务端是否可能处理、脚本是否能读取。只模拟策略，不访问任何 API。
跨源响应交接台
发出请求、读到响应，是两件事
固定目标为 https://api.example.test。改变页面来源、请求形态和响应头，观察 OPTIONS、实际请求与脚本读取分别发生了什么。
尚未运行。先观察请求和服务端条件，再运行这次本地演示。
试一试：保留缺少允许来源的设置，把表单 POST 改为 JSON POST。再设置精确来源与凭据许可，取消「实际响应也返回上述 CORS 头」。三种失败分别挡住了哪一步？
本地有限规则演示，没有网络、HTML 执行或持久化。没有重定向、预检缓存、复杂上传或额外认证；CORS 读取许可不等于授权，也不能单独防止 CSRF。
随手查 / 把理解带回实际工作
理解机制之后，检查这些细节。
实验是简化模型。真实环境需要明确业务规则、验证失败路径，并持续维护配置与证据。
01 / 实用细节
源包含协议、主机与端口
同一域名在不同协议或端口下可以是不同源。策略应匹配实际的 origin，不能只按品牌名称或字符串包含关系判断。[1]
02 / 实用细节
预检通过不是业务授权
OPTIONS 的预检回答浏览器是否允许后续跨源请求。真正接口仍要进行身份、权限与输入检查，不能因为预检放行就返回所有敏感数据。[3][2]
03 / 实用细节
简单请求可能已经到达服务端
浏览器拒绝将响应交给脚本，并不回滚已经发生的写入。这也是 CSRF 防护必须独立设计的原因，不能把控制台的 CORS 错误当成服务端拒绝。[1][2]
04 / 实用细节
反射来源前先做允许列表检查
无条件把请求 Origin 原样写入允许来源，会扩大数据暴露面。支持多个可信来源时需精确校验，动态响应还应考虑 Vary: Origin 与缓存行为。[1][2]
05 / 实用细节
凭据模式与 Cookie 策略同时生效
满足 CORS 凭据要求，并不保证浏览器一定发送 Cookie。SameSite、第三方 Cookie 限制及其他隐私策略仍可能阻止凭据，本练习会明确自己的简化假设。[1][3]
06 / 实用细节
错误要按层排查
分别记录预检结果、实际接口状态和响应头。网络失败、服务端 401/403 与 CORS 不可读是不同问题；不要靠向所有来源开放来掩盖配置错误。[1][2]
从模拟，到验证
找一个获准的环境，实际检查一次。
勾选用于本页自查，不会自动标记整课已学会。练习与清单刷新后重置。
本页已检查 0 / 5 项
API 配了 CORS 白名单后，还需登录和权限验证吗？
能解释原因，再标记学会。
小测结果同步错题本；“已学会”沿用原有本地学习记录。
资料与依据
- MDN · Cross-Origin Resource Sharing ↗
请求分类、响应可读性、凭据与缓存
- OWASP · HTML5 Security / CORS ↗
CORS 与服务端访问控制的边界
- WHATWG Fetch · CORS Protocol ↗
凭据模式、允许来源和浏览器协议判断
本页场景、人物与数据均为教学示例。互动选择不会上传；收藏、已学会与错题沿用当前浏览器本地存储。来源正文核对日期：2026-10-08。