网安60秒丨CORS

要理解CORS漏洞，必须先了解浏览器的一项基础安全机制——同源策略（Same-Origin Policy）。

定义：同源策略规定，一个网页（源）的脚本只能访问同源的资源（即协议、域名、端口完全相同），而无法直接访问其他源的资源。

例如：https://example.com 的页面无法通过JavaScript直接读取 https://api.another.com 的数据。

目的：防止恶意网站窃取用户在其他网站上的敏感信息（如Cookie、个人数据）。

如果所有网站都完全禁止跨域访问，互联网的协作性将大打折扣。

例如：你的前端页面 https://web.com 需要调用后端API https://api.com 的数据。

这时就需要一种安全机制，允许受控的跨域访问，这就是CORS（Cross-Origin Resource Sharing，跨源资源共享）。

CORS的核心：通过服务器设置的HTTP响应头（Headers），明确告诉浏览器哪些外部源可以访问资源。

当浏览器检测到跨域请求时（例如通过JavaScript的fetch或XMLHttpRequest），会触发以下流程：

简单请求 vs 预检请求

CORS本身是安全的，但错误的服务器配置会导致漏洞，攻击者可利用此窃取用户数据。

通配符滥用

服务器设置 Access-Control-Allow-Origin: *（允许所有源访问）。

风险：任何网站均可读取该资源，若涉及敏感数据则直接泄露。

动态信任任意Origin

服务器根据请求头的 Origin 值动态返回 Access-Control-Allow-Origin，但未校验合法性。

示例：

允许携带凭证（Credentials）

若服务器设置 Access-Control-Allow-Credentials: true，且未严格限制Origin，攻击者可利用用户Cookie发起身份伪造攻击。

假设存在一个漏洞网站 https://vulnerable-api.com，其CORS配置如下：

攻击步骤：

严格限制允许的源

避免使用通配符 *，仅允许信任的域名（如 Access-Control-Allow-Origin: https://trusted.com）。

若需动态配置，务必校验请求的Origin是否在白名单中。

谨慎处理Credentials

若非必要，不要设置 Access-Control-Allow-Credentials: true。

若必须携带凭证，确保同时限制Origin（不允许设置为 *）。

合理处理预检请求

明确指定允许的HTTP方法（Access-Control-Allow-Methods）和头（Access-Control-Allow-Headers）。

2021年，某知名社交平台因CORS配置错误，允许任意Origin访问用户个人资料接口。攻击者通过恶意网站窃取用户隐私数据，导致数百万用户信息泄露。

平台最终修复方案为：

CORS漏洞的本质是服务器配置的疏忽，而非协议本身缺陷。

如果一个API需要同时支持Web端和移动端，如何设计安全的CORS策略？

欢迎在评论区分享您的答案！

《网安60秒丨SSTI》