HTTP方法（GET/POST）与CSRF的关联及Sonar告警相关疑问

一、Sonar告警与CSRF的核心关联 #

Sonar的这条规则针对的是同时开放GET和POST方法、且涉及敏感操作的后端端点，告警的核心原因是GET方法的特性会显著放大CSRF攻击的风险，让敏感操作更易被攻击者利用。

二、为什么同时开放GET和POST风险更高？ #

• GET请求的CSRF攻击几乎无门槛：GET请求通过URL传递参数，浏览器会自动携带当前域名的Cookie。攻击者只需构造一个包含恶意GET请求的资源链接（比如<img src="http://你的域名/api/删除数据?id=123">），用户只要加载包含该内容的页面，浏览器就会自动发送GET请求，用户完全无感知，不需要主动点击或提交操作。
• POST请求的CSRF攻击门槛更高：虽然POST也能被CSRF利用，但攻击者通常需要构造表单诱骗用户提交，或者用JavaScript自动提交。但浏览器的同源策略、内容安全策略（CSP）等机制会限制这类操作，用户中招的概率和攻击成功率远低于GET。
• 双方法开放易引发误用：如果端点同时支持GET和POST，开发者可能原本期望敏感操作仅通过POST触发，但攻击者可以利用GET的易攻击性绕开设计预期，把敏感操作转化为可通过URL触发的请求，大幅降低攻击成本。甚至前端可能在某些场景下错误地用GET调用本应POST的接口，进一步放大风险。

三、仅限制POST为何仍有CSRF风险？ #

你说的没错，仅将端点限制为POST确实不能彻底阻止CSRF，但能显著提升攻击门槛：

• POST的CSRF需要攻击者构造恶意页面，诱骗用户访问并触发表单提交；
• 若用JavaScript发起跨域POST请求，会被浏览器同源策略拦截，除非目标接口设置了过于宽松的CORS规则；
• 相比GET的“被动触发”，POST的CSRF需要用户更多的交互（或更复杂的攻击手段），攻击成功率和影响范围都会缩小。

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