CORS 请求中 Referrer 检查到底安不安全？

采涵 Dev 提问于 2026-02-26 10:00:20 阅读 45

安全

我在做前端请求时，后端同事说他们加了 Referrer 检查来防止跨域攻击，但我听说这其实不靠谱？

比如我用 fetch('/api/data') 发请求，浏览器自动带上了 Referer 头，但这个值能被伪造吗？或者在某些环境下根本不会发送？

之前试过在本地开发时（http://localhost:3000）请求测试接口，结果后端因为 Referer 不是白名单域名直接拒绝了，搞得调试很麻烦。

这是不是说明依赖 Referer 做安全校验有隐患？有没有更靠谱的替代方案？

CORS安全

我来解答赞 13 收藏

反馈

2 条解答

司徒洋辰 Lv1

Referrer 这玩意儿确实有点坑。先说结论，它不完全可靠。

浏览器确实会自动带上 Referer 头，但在某些情况下不会发送，比如从 HTTPS 到 HTTP 的请求、隐私模式下、用户禁用了 Referer 等。而且在某些高级操作下（像用一些特殊的代理工具），Referer 是可以被伪造的。

你遇到的本地开发问题很典型。localhost 这种非标准域名确实容易出问题。后端硬编码白名单的做法太死板了，建议后端同事考虑使用更灵活的安全方案。

推荐用 Access-Control-Allow-Origin 配合 CORS 来处理跨域，再结合 JWT 或者签名验证机制。这样既解决了跨域问题，又能保证请求安全。

如果非要保留 Referrer 检查，至少要做个兜底方案，允许调试环境跳过检查。简单粗暴点就是在代码里加个开关变量控制。



// 后端伪代码示例

if (DEBUG_MODE) {

    // 跳过所有安全检查

} else {

    // 正常校验逻辑

}

记住，永远不要把安全性完全寄托在单一的 HTTP 头上，多层防护才是王道。这活儿干多了真挺累的，不过为了系统安全也只能这么来。

2026-03-30 12:18

上官天朝 Lv1

问题应该出在后端把 Referer 当成主要安全校验手段了，这确实不靠谱。

Referer 头是浏览器自动加的，但有几种情况它根本不会带，或者会被清掉：
比如从 HTTPS 页面发请求到 HTTP 接口（浏览器会自动砍掉 Referer），或者用了 fetch('/api', { referrerPolicy: 'no-referrer' }) 这类设置，甚至有些隐私插件或浏览器设置也会屏蔽。
另外，虽然 Referer 在大多数情况下是浏览器生成的、难以被前端 JS 直接伪造，但后端如果只靠它来防跨域，那攻击者完全可以换别的攻击方式，比如直接用 Node.js 写个脚本发请求——根本没浏览器，Referer 都没有，自然绕过。

更关键的是，Referer 是用户可控的上下文产物，不是请求来源的可靠证明。
比如用户点了个外部链接跳转到你页面，再发起请求，Referer 就是外部域名，可能你白名单里压根没这玩意，结果误伤。

真正要防 CSRF，应该用标准方案：
- 前端发请求时带上 credentials: 'include'（配合 Set-Cookie: SameSite=None; Secure）
- 后端用 CSRF Token 校验，比如每次表单或关键请求带一个随机 Token，后端比对
- 或者用双重 Cookie 模式（比如把 Token 写进 Cookie，再让前端在 Header 里带一份，后端比对）

本地调试时被 Referer 拒绝，其实只是暴露了你后端逻辑太依赖 Referer 这个脆弱指标。
建议后端同学把 Referer 检查降级为“日志记录或风控参考”，别当硬性安全门槛，否则开发体验和线上稳定性都会被坑。

2026-02-26 10:02