API 使用 Bearer Token 能天然防御 CSRF（跨站请求伪造） 攻击，其核心原因在于 浏览器不会自动在跨站请求中携带 Bearer Token，而 CSRF 攻击恰恰依赖于浏览器的"自动携带凭证"机制。下面从原理层面详细解释：
一、CSRF 攻击的本质
CSRF 攻击成功的关键有两个前提：
- 用户已通过身份认证（如登录），服务器为其颁发了身份凭证（如 Cookie 中的 Session ID）；
- 浏览器会自动在请求中附带该凭证（比如同域下的 Cookie），无论这个请求是用户主动发起还是由第三方网站诱导发起。
攻击者正是利用第 2 点，在用户不知情的情况下，诱导其浏览器向目标网站（如银行）发送恶意请求（如转账），而浏览器会"忠实地"带上用户的 Cookie，使服务器误以为这是合法操作。
二、Bearer Token 的工作机制
-
Bearer Token（例如 JWT）通常由前端在用户登录后从响应中获取，并手动存储（如 localStorage、sessionStorage 或内存中）；
-
每次调用 API 时，前端需显式地将 Token 添加到请求头中 ，例如：
httpAuthorization: Bearer <your-token> -
浏览器不会自动添加这个 Header，必须由前端 JavaScript 主动设置。
三、为什么 Bearer Token 天然防 CSRF？
| 对比维度 | Cookie（Session） | Bearer Token |
|---|---|---|
| 凭证携带方式 | 浏览器自动附加到同域请求 | 前端手动添加到请求头 |
| 跨站请求是否自动携带 | ✅ 是（除非 SameSite=Strict） | ❌ 否 |
| 攻击者能否伪造有效请求 | ✅ 可以（靠浏览器自动带 Cookie） | ❌ 无法（拿不到 Token） |
关键点在于：
- CSRF 攻击不涉及读取用户数据，只是诱导浏览器发请求；
- 攻击者控制的恶意页面（如
attacker.com）无法通过 JavaScript 读取目标站点（如api.bank.com）的 localStorage 或内存中的 Token（受同源策略限制）； - 因此，攻击者构造的跨站请求无法包含有效的 Bearer Token；
- 服务器收到请求后发现缺少或无效的
Authorization头，直接拒绝，CSRF 失败。
💡 即使 Bearer Token 存在 XSS 风险（可被脚本窃取），但 XSS ≠ CSRF。CSRF 不需要窃取凭证，只依赖自动携带；而 Token 不自动携带，所以 CSRF 无法成立。
四、注意事项
虽然 Bearer Token 天然防 CSRF，但仍需注意：
- 不要把 Token 存在 Cookie 里 （尤其是未设
HttpOnly的 Cookie），否则可能重新引入 CSRF 风险； - 仍需防范 XSS：如果 Token 存在 localStorage，XSS 可窃取它，进而冒充用户；
- 务必使用 HTTPS：防止 Token 在传输中被中间人窃听。
总结
Bearer Token 能天然防御 CSRF，是因为它不依赖浏览器自动携带机制，而是由前端主动、显式地附加到请求中。攻击者无法在跨站请求中注入有效的 Token，因此无法伪造用户身份操作。
这正是现代无状态 API（如 RESTful API）普遍采用 Token 认证而非传统 Cookie + Session 的重要安全优势之一。