自定义HTTP头能否防范CSRF？相关原理及安全性求证

一、原理拆解 #

浏览器的**同源策略（SOP）**和跨域资源共享（CORS）规则是这里的核心逻辑：

• 若在自身网站页面发起请求到同源服务器，浏览器不会限制自定义HTTP头的发送，完全允许站点给自己的服务器传递任意自定义头。
• 若发起跨域请求（比如恶意站点向目标网站发送请求），只要请求携带自定义HTTP头，就会被判定为「非简单请求」。此时浏览器会自动先发一个OPTIONS预检请求，询问目标服务器是否允许该跨域请求携带指定自定义头。只有服务器通过响应明确许可（返回的Access-Control-Allow-Headers包含该自定义头），浏览器才会发送实际请求；否则直接拦截请求，不会将带自定义头的请求发送出去。

这就是Invicti表述中“浏览器阻止站点向其他站点发送自定义HTTP头，但允许向自己发送”的底层逻辑。

二、表述正确性确认 #

这个说法完全正确，但需要补充关键细节：

• 并非跨域场景绝对无法发送自定义头，而是浏览器会通过预检机制拦截未获许可的请求。攻击者的恶意站点不可能操控目标服务器的CORS配置，必然无法通过预检，最终导致带自定义头的跨域请求无法送达目标服务器。
• 对比简单请求（比如仅使用GET/POST方法、仅携带标准HTTP头的请求），这类请求不会触发预检，攻击者可跨域发送，但自定义头的请求必然触发预检，恶意站点根本绕不开这一拦截，实际效果就是跨域时自定义头无法成功发送。

三、自定义头存放CSRF令牌能否避免伪造 #

绝对可以，核心原因如下：

• CSRF攻击的本质是利用浏览器自动携带用户登录Cookie的特性，在用户不知情的情况下发起跨域请求。但攻击者的恶意脚本无法在跨域请求中设置自定义HTTP头——浏览器会直接拦截这类请求，根本无法抵达目标服务器。
• 后端只需做两项校验：一是要求接口必须携带指定的自定义HTTP头；二是校验头中的CSRF令牌与用户会话中存储的令牌一致。攻击者既无法伪造该自定义头，也无法获取合法令牌并塞进头中，自然就能彻底阻断CSRF攻击。

内容的提问来源于stack exchange，提问作者RazorMx