JavaScript跨域本身非攻击，但CORS响应头错误配置会导致敏感数据泄露、凭据劫持或成为CSRF跳板；防御核心是精准授权、最小暴露、分层隔离，须严格校验Access-Control-Allow-Origin、绑定凭据、收紧预检、叠加CORP/COEP/COOP纵深防护。
JavaScript 跨域本身不是攻击，但错误配置 CORS 相关响应头会直接导致敏感数据泄露、凭据劫持甚至成为 CSRF 攻击跳板。防御的关键不在于“允许跨域”，而在于“精准授权、最小暴露、分层隔离”。以下是从响应头层面最实用、最常被忽略的防御要点。
严格校验并限定 Access-Control-Allow-Origin
这是最核心、也最容易出错的头。生产环境绝不能写 Access-Control-Allow-Origin: *，尤其当涉及用户身份（如 Cookie、Token）时，该配置等于公开放行所有站点读取你的接口响应。
- 必须动态比对请求头中的 Origin 值，仅对白名单域名（如
https://app.example.com）回写对应值 - 禁止拼接多个源（如
http://a.com, http://b.com），也不支持逗号分隔或正则匹配 - 若需支持多源且带凭据，应在后端代码中做显式判断，逐个匹配后返回唯一匹配的 Origin 值
凭据与 Origin 必须强绑定
只要设置了 Access-Control-Allow-Credentials: true，Access-Control-Allow-Origin 就不能再是 *——浏览器会直接拒绝响应。这是硬性规则，不是建议。
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 前端发起请求时必须显式启用凭据：
fetch(url, { credentials: 'include' })或xhr.withCredentials = true - 后端响应中，
Allow-Origin和Allow-Credentials: true必须成对出现，且 Origin 值必须为具体协议+域名+端口（如https://admin.example.org:3001） - 如果某个接口不需要用户上下文（如公开天气 API），就不要开凭据，避免扩大攻击面
收紧预检与方法控制
OPTIONS 预检请求是攻击者探测你 CORS 策略的第一步。宽松的 Allow-Methods 或 Allow-Headers 可能暴露内部接口设计，甚至辅助构造更隐蔽的 CSRF。
立即学习“Java免费学习笔记（深入）”；
-
Access-Control-Allow-Methods只列真正需要的动词，如GET, POST, OPTIONS；禁用PUT、DELETE除非业务强依赖 -
Access-Control-Allow-Headers显式声明允许的自定义头（如Authorization, X-Request-ID），禁用通配符* - 对所有 OPTIONS 请求立即返回 200 并终止处理，防止业务逻辑意外执行（如日志写入、计数器递增）
叠加 CORP、COEP、COOP 构建纵深隔离
CORS 解决的是“谁可以读我的响应”，而 CORP/COEP/COOP 解决的是“谁可以加载我的资源”和“我的页面能否被嵌入/打开”。三者配合才能阻断现代跨站数据窃取链路。
-
Cross-Origin-Resource-Policy: same-site —— 阻止其他站点通过
<img>、<script>、fetch()加载你的敏感资源（如用户头像、配置文件） -
Cross-Origin-Embedder-Policy: require-corp —— 强制所有跨域资源必须声明
CORP，否则加载失败，为SharedArrayBuffer等高危 API 提供前提 -
Cross-Origin-Opener-Policy: same-origin —— 切断恶意页面通过
window.open()打开你的页面后对其 DOM 的访问能力，防止侧信道攻击
