CORS 请求中 Referrer 检查到底安不安全？
我在做前端请求时，后端同事说他们加了 Referrer 检查来防止跨域攻击，但我听说这其实不靠谱？
比如我用 fetch('/api/data') 发请求，浏览器自动带上了 Referer 头，但这个值能被伪造吗？或者在某些环境下根本不会发送？
之前试过在本地开发时（http://localhost:3000）请求测试接口，结果后端因为 Referer 不是白名单域名直接拒绝了，搞得调试很麻烦。
这是不是说明依赖 Referer 做安全校验有隐患？有没有更靠谱的替代方案？
- 2
回答
26浏览
React中POST请求为什么被CORS拦截？预检请求没发出去？
在React项目里用fetch发POST请求到第三方API时，浏览器突然报CORS错误。我明明设置了headers里的Content-Type为application/json，但控制台显示"Resp...
- 2
回答
29浏览
为什么我的Ajax请求突然报CORS错误？之前还能正常工作？
我在用Vue写一个表单提交功能，突然发现用axios发POST请求到后端PHP接口时，浏览器直接报CORS错误，明明昨天还能正常工作... 前端代码没改过，就是普通的axios配置：axios.pos...
- 2
回答
562浏览
CORS设置中用*通配符有什么安全风险？为什么改用具体域名反而报错？
我在后端设置了CORS的Access-Control-Allow-Origin为"*"，结果被安全审计指出存在漏洞。改成允许特定域名后，浏览器却报"Response to preflight requ...
- 1
回答
9浏览
前端用代理解决CORS问题，为什么本地开发能行上线就挂了？
我在本地开发时用 Vite 的 proxy 配置成功绕过了 CORS，请求第三方 API 没问题。但部署到线上后，直接报跨域错误，明明线上也配了 Nginx 反向代理，怎么就不生效了？ 本地配置是这样...
- 2
回答
14浏览
Nginx配置CORS后前端还是跨域，哪里出问题了？
我在本地用Vue开发，请求后端API一直报跨域错误，明明已经在Nginx里加了CORS头，但浏览器还是拦着不让过，到底是哪没配对？ 我试过在Nginx的location块里加add_header，也重...
- 1
回答
13浏览
CORS 中 Access-Control-Allow-Methods 设置后为啥还是报错？
我前端用 fetch 发了个 DELETE 请求，但浏览器控制台一直报 CORS 错误，说 method 不被允许。后端明明已经加了 Access-Control-Allow-Methods: GET...
- 2
回答
40浏览
CORS Origin检查时，为什么设置了Access-Control-Allow-Origin却还是被拦截？
我前端项目在调用后端API时遇到了CORS问题，明明在服务器响应头里设置了Access-Control-Allow-Origin: *，但Chrome还是报错"Origin http://localh...
- 1
回答
11浏览
CORS白名单配置后前端还是跨域，咋回事？
我后端已经加了CORS白名单，只允许我们自己的域名访问，但本地开发时用 localhost:8080 还是报跨域错误，是不是哪里没配对？ 我在 Vue 里是这样发请求的： <script set...
- 1
回答
36浏览
CORS 请求中 Access-Control-Allow-Headers 到底该怎么配？
我在前端用 fetch 发了个带自定义 header 的请求，比如 X-Custom-Token，但浏览器报错说这个 header 被 CORS 策略拦了。后端是用 Express 写的，我已经加了 ...
- 1
回答
71浏览
CORS配置能防御CSRF攻击吗？应该如何正确设置？
我在用Spring Boot配置CORS时发现，设置了allowedOrigins为可信域名，但测试时用其他域名发起带token的POST请求居然成功了，这不还是存在CSRF漏洞吗？ 后端配置是这样写...
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 检查降级为“日志记录或风控参考”，别当硬性安全门槛，否则开发体验和线上稳定性都会被坑。