为什么你的网银余额不会被陌生网站偷走？

当你在银行APP上查看余额后，又随手点开一个新闻网站，有没有想过：为什么新闻网站的代码不能偷偷访问你的银行账户信息？这背后，同源策略（SOP） 和跨域资源共享（CORS） 就像浏览器的“门神”和“访客通行证”，一个严防死守，一个灵活放行，共同筑起了Web安全的第一道防线。

一、同源策略（SOP）：浏览器的“门禁系统”

1.1 什么是“同源”？—— 三个“一模一样”才叫一家人

1995年，网景浏览器首次引入同源策略，核心规则很简单：只有“协议、域名、端口”三者完全相同的网页，才算“一家人”，才能互相读取数据。比如：

https://www.example.com:443 和 https://www.example.com 是同源（端口443是HTTPS默认端口，可省略）；
https://www.example.com 和 http://www.example.com 不是同源（协议不同：https vs http）；
https://www.example.com 和 https://api.example.com 不是同源（域名不同：www vs api）。

▲ 同源策略示意图：只有协议、域名、端口完全一致，浏览器才允许数据交互

1.2 SOP的“铁律”：这三件事绝对禁止

同源策略像一道无形的墙，明确禁止“外人”做三件事：

读Cookie/Storage：A网站的JS无法读取B网站的Cookie（比如你淘宝的登录状态不会被陌生网站获取）；
操作DOM：A网站的iframe无法修改B网站的页面内容（防止恶意嵌套钓鱼页面）；
发Ajax请求：A网站的Ajax不能读取B网站的响应数据（即使请求能发出，浏览器也会拦截响应）。

但凡事有例外：<img> <link> <script> 等标签加载资源时不受SOP限制（比如你能在自己的网页里引用百度的图片），但JS仍无法读取这些资源的具体内容（比如无法获取图片的像素数据）。

二、CORS：给“访客”发一张可控的“通行证”

2.1 为什么需要CORS？—— 当“门禁”太严，合法业务也会被挡在门外

随着前后端分离架构普及，前端（http://localhost:3000）和后端（https://api.example.com）往往不在同一个“源”，SOP的严格限制会导致正常数据请求被拦截。这时，跨域资源共享（CORS） 应运而生，它允许服务器主动声明：“哪些外部网站可以安全地访问我的资源”。

2.2 CORS的“对话”流程：先“敲门”再“进门”

CORS通过HTTP头实现浏览器与服务器的“对话”，核心分为两种场景：

简单请求：直接放行（无需“预约”）

如果请求满足：

方法是 GET/POST/HEAD；
请求头只包含 Content-Type（仅限 application/x-www-form-urlencoded/multipart/form-data/text/plain）等“简单头”，
浏览器会直接发送请求，并在响应中检查 Access-Control-Allow-Origin 头：如果该头包含当前网站的域名，就放行数据；否则拦截。

预检请求（Preflight）：先“报备”再行动

如果请求用了 PUT/DELETE 方法，或带了 Authorization 等自定义头，浏览器会先发送一个 OPTIONS 请求“报备”：

请求头：告诉服务器“我要用什么方法、什么头”（Access-Control-Request-Method/Access-Control-Request-Headers）；
响应头：服务器回复“允许哪些源、方法、头”（Access-Control-Allow-Origin/Allow-Methods/Allow-Headers），并声明“报备结果有效期”（Access-Control-Max-Age，比如86400秒=24小时）。

▲ CORS预检请求流程：浏览器先发送OPTIONS“报备”，服务器同意后才发送实际请求

三、当“通行证”发错了：CORS配置错误有多危险？

CORS的灵活性依赖于服务器的正确配置，但一个小小的疏忽就可能变成“安全后门”。以下两种错误配置堪称“高危操作”：

3.1 案例1：“谁来都放行”—— 通配符+允许凭证

2025年5月，Google Chrome曝出CVE-2025-4664漏洞，攻击者利用SOP执行漏洞，诱导用户访问恶意网站后，竟能让浏览器携带完整URL发起请求，导致敏感信息泄露（如用户搜索记录、订单详情）。这一漏洞被发现时已在野利用，影响超过千万用户，最终通过紧急更新Chrome 136版本修复。

类似的，若服务器配置：

Access-Control-Allow-Origin: *  // 允许所有网站访问
Access-Control-Allow-Credentials: true  // 允许携带Cookie

看似“方便”，实则等于把家门钥匙插在门外——攻击者可伪造请求，用受害者的Cookie访问敏感数据（如用户余额、个人信息）。

3.2 案例2：“误认亲戚”—— 宽松的Origin校验

2024年，某电商平台因CORS配置错误被曝出漏洞：服务器校验 Origin 时仅检查“是否包含 example.com”，攻击者构造 attacker-example.com 域名，竟被判定为“可信源”，最终导致用户订单信息泄露。

正确的做法是严格校验Origin白名单，比如：

// 后端伪代码：只允许指定域名访问
const allowedOrigins = ['https://www.example.com', 'https://app.example.com'];
if (allowedOrigins.includes(req.headers.origin)) {
  res.setHeader('Access-Control-Allow-Origin', req.headers.origin);
}

▲ 浏览器控制台显示CORS错误：服务器未正确返回
Access-Control-Allow-Origin头

四、开发者必知：CORS配置的“安全口诀”

4.1 三个“绝对不要”

不要用 Access-Control-Allow-Origin: * 搭配 Allow-Credentials: true（浏览器会直接拦截这种矛盾配置）；
不要动态反射 Origin 头而不校验（比如 res.setHeader('Allow-Origin', req.headers.origin)，等于“谁敲门就放谁进”）；
不要忽略预检请求（OPTIONS 请求需要正确响应，否则复杂请求会被浏览器拦截）。

4.2 两个“推荐做法”

设置合理的 Max-Age：比如 Access-Control-Max-Age: 86400（缓存预检结果24小时，减少重复请求）；
用 Vary: Origin 头优化缓存：告诉CDN“不同Origin的请求要分开缓存”，避免缓存污染。

五、安全与便利的平衡艺术

同源策略（SOP）是“底线安全”，像一道不可逾越的门禁，确保陌生网站无法随意读取你的数据；跨域资源共享（CORS）是“灵活通行证”，让合法的跨域请求（如前端调用后端API）得以实现。

2025年，随着浏览器安全机制升级（如Chrome 136强化SOP执行、Edge 135优化根证书策略），开发者更需注意：安全配置没有“图方便”的捷径。记住：SOP和CORS不是“技术障碍”，而是保护用户数据的“隐形铠甲”——毕竟，在Web世界里，“安全”永远比“方便”更重要。

▲ 当CORS配置错误时，浏览器会弹出安全警告，阻止数据泄露

参考资料：

MDN Web Docs：同源策略
Google安全公告：CVE-2025-4664漏洞修复
CSDN博客：CORS配置错误案例复现

浮头导航网

专注编程技术分享的开发者社区

浏览器安全的“通行证”:SOP和CORS如何守护你的数据?