CORS 报错该怎样修：凭据、允许来源与接口鉴权的边界

前端出现跨域报错时，把所有来源都放行看似省事，却可能让敏感响应暴露给不应读取它的网站。排查应先明确接口是否公开、是否需要用户凭据，以及哪些页面有合法读取需求。

先分清来源与身份

来源由协议、主机和端口共同决定。开发环境、正式环境及嵌入式页面应分别登记，不能用模糊的域名后缀包含判断代替严格匹配。未登记的来源要有明确处理方式，不应把请求里的 Origin 原样反射回响应。

MDN 说明，携带凭据的跨来源响应不能使用通配符作为 Access-Control-Allow-Origin。CORS 是浏览器执行的跨来源读取机制，不是服务端登录验证，也不能阻止所有请求发出，因此不能替代接口授权或 CSRF 防护。

按请求链路排查

1. 在浏览器开发者工具中区分预检请求与实际业务请求，记录失败发生在哪一步。
2. 核对允许的方法、请求头和凭据设置是否与业务需要一致，避免为解决一个接口问题开放所有能力。
3. 检查反向代理、应用和缓存是否重复或矛盾地写入响应头。
4. 若响应会根据 Origin 变化，核对缓存隔离与 Vary 等策略，防止把一个来源的响应规则复用给另一个来源。

验收不应只测“能用了”

用受控的允许来源、不允许来源、匿名会话和登录会话分别测试。预期允许的浏览器调用应成功，非允许页面不能读取私密响应；与此同时，无权限请求即便由命令行客户端发出，服务端仍应拒绝。

对完全公开且无需凭据的数据，可以按业务需要采用更开放的策略。对管理或个人数据接口，应把来源清单当作可审计配置，前端域名下线时及时删除。

参考：MDN：Cross-Origin Resource Sharing。核对日期：2026年10月4日。