关于HTTP安全方法的定义及违规使用后果的技术咨询

HTTP协议中的安全方法是RFC 9110明确约定的一类只读语义方法，包含GET、HEAD、OPTIONS、TRACE四种，核心约定为：

请求方法被认为是“安全的”，当且仅当该方法的定义语义本质上是只读的，即客户端请求该方法时，不会期望在源服务器上产生任何状态变更，也不会因此对服务器造成任何伤害。

如果服务端违反上述语义约定，使用安全方法实现资源创建、修改、删除等变更逻辑，会产生以下明确的负面影响：

• 缓存污染：HTTP网络体系中的各级缓存（浏览器缓存、CDN、服务端缓存）默认会对安全方法的响应进行缓存，不会每次请求都透传到源站。如果GET请求实际执行了修改操作，不仅可能出现缓存的旧响应覆盖真实结果的情况，还可能因为缓存命中导致重复执行变更逻辑，产生非预期的状态修改。
• 非主动触发的误操作：搜索引擎爬虫、浏览器预加载功能都会默认主动请求页面内的所有GET链接，不需要用户主动点击。如果变更逻辑绑定GET接口，很可能出现爬虫爬取站点后批量触发数据修改、删除的事故；此外用户使用浏览器前进后退功能时，也会自动重复发起GET请求，导致重复提交问题。
• 安全风险升高：WAF、API网关等安全中间件默认不会对安全方法做CSRF校验，攻击者可以很容易构造恶意页面诱导用户点击，在用户完全不知情的情况下触发GET变更接口，执行数据篡改操作。此外大部分服务器默认会丢弃GET请求的请求体，把鉴权、参数放在GET请求体里的逻辑会直接失效。
• 运维与协作成本上升：监控、审计体系默认会将安全方法归类为只读操作，排查数据变更故障时不会优先检索GET类请求的日志，大幅提升问题排查难度；同时主流API设计规范均遵循HTTP方法语义，混用方法会导致对接开发者因为对方法的固有认知写出BUG，提升协作成本。

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