采用JavaScript签名请求后，是否还需要CSRF防护措施？

传统CSRF防护手段回顾 #

过去缓解CSRF攻击的主流方案包括：

• 会话存储Nonce：在会话中存储随机Nonce，请求时携带该值，服务器比对验证。缺点是需要占用服务器会话存储资源。
• 签名双提交Cookie：OWASP推荐的替代方案，无需服务器存储，通过Cookie中的值和请求参数/Header中的签名值比对完成验证。
• 基于SessionId的HMAC Nonce：用服务器侧存储的密钥对SessionId生成HMAC作为Nonce，服务器无需额外存储会话数据，只需重新计算HMAC即可验证请求合法性。

基于SubtleCrypto的请求签名方案 #

如今SubtleCrypto API已在所有主流浏览器中普及，服务器可要求前端通过JavaScript对请求进行签名——比如使用不可导出的椭圆曲线私钥或其他非对称密钥对，此时不再依赖Session Cookie作为Bearer令牌。

核心问题解答：是否还需要传统CSRF防护？ #

答案是完全不需要，理由如下：

1. 同源策略限制：只有当前顶级域名下加载的JavaScript才能访问到浏览器端存储的不可导出私钥，跨站域名无法获取该密钥，自然无法生成符合要求的请求签名，跨站请求会直接被服务器拒绝。
2. 安全性更优：相比依赖Session Cookie作为Bearer令牌的方案，即使攻击者截获了令牌（若存在），没有私钥就无法伪造签名请求，从根源上避免了令牌被盗用的风险。

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