HTTP 方法详解：GET、POST、PUT、DELETE、HEAD、OPTIONS、PATCH、CONNECT、TRACE
为什么审计师要死磕这些方法？
说实话，很多人觉得 HTTP 方法就是 REST API 的标配，看看文档就完事了。但在安全审计里，这些方法就是攻击者的导弹发射架。我经手过好几个案例——攻击者利用不安全的 PUT 方法直接往服务器写 webshell，或者用 TRACE 方法偷 Cookie。你想想看，如果连方法的安全属性都搞不清楚，审计报告就是废纸。
先搞懂两个核心概念：安全性与幂等性
安全性：调用这个方法会不会改变服务器资源？不会，就是安全的。注意，日志记录不叫改变资源。
幂等性：不管你调用 1 次还是 100 次，资源状态都一样。嗯，这个在重试场景里特别重要。
审计口诀：安全的方法可以在不通知用户的情况下缓存；幂等的方法可以放心重试。
逐个方法拆解
GET —— 最老实的请求
安全 + 幂等。GET 只读不写，这是铁律。但我在项目里见过有人用 GET 传 JSON body 做删除操作——我直接标记为高危。记住：审计时如果看到 GET 请求导致资源变化，不是设计错误就是漏洞。
# 标准 GET，安全且幂等
curl -X GET https://api.example.com/users/42
# 危险做法：用 GET 做删除
curl -X "GET" -d '{"action":"delete"}' https://api.example.com/users/42 # ❌ 审计必报HEAD —— GET 的轻量版
安全 + 幂等。只返回响应头，不返回 body。常用于探测资源是否存在、检查缓存有效性。审计时要注意：有些 WAF 会阻断 HEAD 方法，但正常业务里 HEAD 不会带来任何副作用。
OPTIONS —— 探测服务器能力
安全 + 幂等。返回服务器支持的 HTTP 方法。在 CORS 预检里很常见。但攻击者会用 OPTIONS 扫描可用的不安全方法。我曾经发现一个服务器居然允许 TRACE 和 PUT，就是通过 OPTIONS 暴露的。
DELETE —— 不安全但幂等
不安全（会删资源），但幂等（删掉后资源就不存在了，再删还是不存在）。审计难点：多次 DELETE 返回 200 还是 404 都不影响幂等性定义。我在审计时发现一个系统 DELETE 第一次返回 200，第二次返回 404，虽然幂等，但日志里需要区分是正常删除还是重复攻击。
PUT —— 覆盖式更新
不安全但幂等。PUT 会把整个资源替换成你发送的表示。核心是你要发送完整资源。如果能成功替换，多次请求结果一样。我曾经遇到过一个团队用 PUT 做部分更新，结果幂等性全乱套了。
# 幂等：第一次创建用户42，第二次覆盖用户42
curl -X PUT -d '{"name":"Alice","age":30}' https://api.example.com/users/42PATCH —— 部分更新，非幂等
不安全且非幂等。PATCH 只发送变更部分，而且依赖当前资源状态。举个例子：一个 PATCH 请求给计数器 +1，你发两次就加了两次。这就是非幂等。审计时要注意 PATCH 操作的原子性和重复防护。
POST —— 万用工作马，非幂等
不安全且非幂等。创建资源、提交表单、触发动作……几乎都在用。审计最头疼的就是 POST，因为非幂等意味着重试可能导致重复订单、重复扣款。我建议对 POST 接口做幂等性改造：加一个幂等键（Idempotency-Key），这是很多支付系统的标配。
CONNECT —— 隧道代理
既不安也不幂等。CONNECT 用来建立隧道，主要用于 HTTPS 代理。在审计中很少见到，但一旦出现就要高度警惕——攻击者可能用它绕过防火墙做内网穿透。
TRACE —— 调试方法，高危
不安全？其实 TRACE 理论上不会改变资源，但它会原样返回请求。攻击者可以用 TRACE + XSS 劫持 Cookie（跨站追踪攻击）。现在大多数生产环境都禁止 TRACE。我看到一次审计报告里服务器开放了 TRACE，马上标记为严重。
快速查阅表
| 方法 | 安全 | 幂等 | 典型场景 | 审计风险 |
|---|---|---|---|---|
| GET | ✅ | ✅ | 读取资源 | 低 |
| HEAD | ✅ | ✅ | 检查元数据 | 低 |
| OPTIONS | ✅ | ✅ | CORS 预检 | 中（暴露方法清单） |
| DELETE | ❌ | ✅ | 删除资源 | 中（需鉴权） |
| PUT | ❌ | ✅ | 完整替换 | 中（上传漏洞） |
| PATCH | ❌ | ❌ | 部分更新 | 高（非幂等） |
| POST | ❌ | ❌ | 创建/提交 | 高（重复提交） |
| CONNECT | ❌ | ❌ | 隧道代理 | 高（代理滥用） |
| TRACE | ✅* | ✅ | 调试回显 | 严重（XST攻击） |
*TRACE 在安全定义上算“无副作用”，但实际风险极大，大多审计标准把 TRACE 视为不安全方法。
我曾经接手一个外发通道审计，发现业务系统对 PUT 接口没有做鉴权，攻击者直接上传了 JSP 文件。嗯，从那以后我每看到一个 PUT 请求，第一反应就是检查写入路径是否在白名单内。
审计中的实用技巧
- 用 OPTIONS 摸清服务器底牌，但别只依赖它——有些服务器会隐藏危险方法。
- 对非幂等方法（POST/PATCH）必须要求业务方提供幂等性方案（例如幂等键或乐观锁）。
- TRACE 和 CONNECT 只要在生产环境出现，直接封禁，不要犹豫。
- 如果看到 PUT 请求的 body 里包含文件内容，重点审计目标路径是否可执行。
我习惯在审计脚本里先发一个 OPTIONS 请求，再对每个返回的方法做一次安全属性验证。效率很高，覆盖也全。
一张图看懂方法与属性
写在最后
方法本身的定义不难，难的是在流量审计里快速识别异常。我个人习惯是把每个方法的安全性和幂等性背下来——不，不是背表，是理解为什么。你想想看，如果攻击者用 PUT 上传了 webshell，那不是方法的错，是审计没发现非幂等方法被滥用了。
下次你看到一条外发流量带着 PUT 方法，心里就亮红灯吧。