CSRF与Ajax跨域：为何浏览器的安全边界未能奏效？

提到 CSRF（跨站请求伪造），很多人会联想到浏览器的 Ajax 跨域限制。从字面上看，“跨域”限制似乎天然能克制“跨站”攻击，但在实践中，这个认知往往会导致一个令人困惑的现象：明明浏览器开发者工具显示跨域请求被拦截了，为什么后台服务器还是执行了该请求？

这是因为浏览器对 Ajax 跨域请求的拦截，本质上拦截的是服务器返回的 HTTP 响应报文，而非 HTTP 请求报文。那个由攻击者精心构造的恶意请求，其实已经顺利穿越了浏览器的“防线”，成功抵达了服务器端。服务器在处理这个请求时，通常会根据附带的 Cookie 等凭证信息，认为这是用户的合法操作，从而执行了相应的业务逻辑（例如转账、改密）。直到服务器准备将响应发回时，浏览器才会根据 CORS（跨源资源共享）策略，检查响应头中的 Access-Control-Allow-Origin 等字段。如果不符合策略，浏览器会阻止前端 JavaScript 代码读取此响应，但此时请求早已执行完毕。

简而言之，CORS 是一种为了保护“客户端数据安全”而设计的机制，它防止恶意网站读取来自另一个源的数据。而 CSRF 攻击的焦点在于“欺骗服务器执行非本意的操作”，攻击者并不关心服务器返回的响应内容。因此，仅依靠 CORS 并无法防御 CSRF。

在主流浏览器全面支持 Cookie 的 SameSite 属性之前，防御 CSRF 主要依靠服务端校验 Referer/Origin 请求头，或使用 CSRF Token。理解 CORS 与 CSRF 在防御目标上的这一关键区别，对于构建安全的 Web 应用至关重要。如果你想深入探讨更多前后端安全与实践经验，欢迎来 云栈社区 交流。