为什么要禁用不安全的 HTTP 请求方法？从安全整改实践谈起

背景

应用安全部门对仓库代码进行安全审计时，发现代码中包含除 POST 以外的其他不安全请求方法（PUT、DELETE ），要求限期整改，禁止使用除 GET、POST 以外的请求方法。

在 Web 开发和安全防护中，HTTP 请求方法（如 GET、POST、PUT、DELETE 等）扮演着重要角色。然而，某些 HTTP 方法如果配置不当，会带来严重的安全风险，甚至导致数据泄露、篡改或服务器入侵。因此，在 Web 服务器或 API 设计中，合理管理和限制 HTTP 方法的使用至关重要。

HTTP 请求方法简介

GET

GET 方法请求一个指定资源的表示形式，使用 GET 的请求应该只被用于获取数据。

HEAD

HEAD 方法请求一个与 GET 请求的响应相同的响应，但没有响应体。

POST

POST 方法用于将实体提交到指定的资源，通常导致在服务器上的状态变化或副作用。

PUT

PUT 方法用有效载荷请求替换目标资源的所有当前表示。

DELETE

DELETE 方法删除指定的资源。

CONNECT

CONNECT 方法建立一个到由目标资源标识的服务器的隧道。

OPTIONS

OPTIONS 方法用于描述目标资源的通信选项。

TRACE

TRACE 方法沿着到目标资源的路径执行一个消息环回测试。

PATCH

PATCH 方法用于对资源应用部分修改。

安全方法（Safe Methods）

如果请求方法的定义语义本质上是只读的，则认为它们是“安全的”，即，客户端不会请求，也不会期望，将安全方法应用于目标资源会导致源服务器上的任何状态更改。同样，合理使用安全方法不会对源服务器造成任何损害、财产损失或不寻常的负担。

安全方法的定义并不妨碍实现包含可能有害的行为、不完全只读的行为或在调用安全方法时导致副作用的行为。但重要的是，客户端没有请求该额外行为，因此不能对此负责。

RFC7231 标准中定义的安全方法包含：GET、HEAD、OPTIONS、TRACE

Of the request methods defined by this specification, the GET, HEAD, OPTIONS, and TRACE methods are defined to be safe.

幂等方法（Idempotent Methods）

使用该方法的多个相同请求对服务器的预期效果与单个此类请求的效果相同。即，同样的请求被执行一次与连续执行多次，对服务器的预期影响是相同的。

RFC7231 标准中定义的幂等方法包含：PUT、DELETE、GET、HEAD、OPTIONS、TRACE

Of the request methods defined by this specification, PUT, DELETE, and safe request methods are idempotent.

可缓存方法（Cacheable Methods）

请求方法可以定义为“可缓存的”，以指示允许存储对它们的响应以供将来重用。

RFC7231 标准中定义的幂等方法包含：GET、HEAD、POST

this specification defines GET, HEAD, and POST as cacheable, although the overwhelming majority of cache implementations only support GET and HEAD.

安全方法一定是幂等方法，幂等方法不一定是安全方法。

PATCH is neither safe nor idempotent as defined by [RFC2616]

PATCH 既不安全也不幂等。

代码重检

由于跨职能组协作，技术负债累积等历史原因，重检过程中发现项目使用的 HTTP 请求方式包含 XMLHttpRequest、axios、fetch。只有在极个别模块 axios 请求方式中使用了 DELETE、PUT 请求方法，除 GET、POST 外再无其他请求方法。

由于涉及到的 API 不多（10 个上下），决定在原 API 配置中直接修改 method 为 POST。还有一种方案，在 axios 请求拦截器中进行拦截，对 GET、POST 以外的请求方法的 config.method 进行重写。

axios.interceptors.request.use(config => {  if (['DELETE', 'PUT'].includes(config.method.toUpperCase())) {    config.method = 'POST';    config.data._method = config.method; // 添加操作标识  }  return config;});

同时，本次重检也暴露出了在以往开发、评审过程中存在的一些问题。开发规范不完善/不遵守，代码评审形式化等，亟需整改。

解决方案

• 补充开发规范，原则上只允许使用统一封装过的 axios 请求方式（推荐）

• 针对安全问题可修改 web 服务器 Nginx 配置

location / {  if ($request_method !~ ^(GET|POST)$) {    return 405;  }}

安全隐患

• PUT 方法的风险

PUT 方法允许客户端直接上传文件到服务器。如果未严格限制上传路径、文件类型和权限，攻击者可能上传恶意文件（如 Webshell、病毒等），导致服务器被控制或数据泄露。

• DELETE 方法的风险

DELETE 方法允许删除服务器上的资源。如果未实施严格的权限验证（如仅允许管理员操作），攻击者可能利用此方法删除业务数据或系统文件，导致服务瘫痪。

• TRACE 方法的风险

TRACE 方法会回显客户端发送的请求内容，包括 HTTP 头（如 Cookie、Authorization）。攻击者可通过恶意脚本诱导用户发送 TRACE 请求，窃取敏感信息（如会话 Cookie）。通过 TRACE 返回的请求详情，攻击者可能探测服务器配置或内部网络结构，辅助进一步攻击。

拓展

1. 简单请求（simple method/simple header）是 CORS 规范 中的提法，现已废弃。新的 CORS 规范为 Fetch 标准
   

2. 前端开发中常见请求方式比较

• XMLHttpRequest

• 兼容性好

• 细粒度控制

• 回调地狱

• 原生 API 笨重

• axios

• 链式调用，Promise 语法，支持浏览器、Node.js

• 拦截器（拦截请求/响应）

• fetch

• 浏览器原生支持，基于 Promise

• 支持流式数据处理，适合处理大文件或流数据

• 默认不携带 Cookie

• HTTP 错误不会触发 catch

• webSocket

• 全双工双向通信协议，基于 TCP，适用于实时场景

• 客户端与服务器保持长连接，支持实时数据推送

总结

允许 PUT、DELETE、TRACE 等方法本身并非绝对危险，但需配合严格的安全措施。若配置不当或缺乏应用层防护，这些方法会显著增加服务器被攻击的风险。遵循“最小权限原则”，仅开放必要功能，是保障安全的关键。

参考资料

• MDN
  

• RFC7231
  

• RFC5789
  

• HTTP 资源与规范
  

📌 你是否检查过你的 Web 服务器支持的 HTTP 方法？赶快测试一下，确保你的服务器不暴露于潜在攻击之中！ 🚀