危险的HTTP方法：TRACE、PUT和DELETE是如何被暴露的
HTTP服务器可以通过响应OPTIONS请求来声明自己支持哪些方法。当这个列表包含生产环境中不需要的危险方法——TRACE、PUT、DELETE、PATCH或CONNECT——时，你就等于给了攻击者一张潜在入口的地图。AppSafe向你网站的根URL发送OPTIONS请求，并标记在Allow或Access-Control-Allow-Methods响应头中发现的任何危险方法。
这是什么
任何HTTP服务器都可以用一个Allow响应头来回答OPTIONS请求，列出它接受的方法：GET、POST、HEAD、OPTIONS，以及其他任何支持的方法。一些框架和反向代理会在同一个响应中添加Access-Control-Allow-Methods。这些请求头都不是必需的，但当它们存在时，会准确地告诉任何调用者该尝试哪些HTTP动词。
AppSafe向你的源站发送OPTIONS请求，检查两个响应头中是否包含危险方法列表中的方法：TRACE、PUT、PATCH、DELETE和CONNECT。TRACE会得到独立的高危告警；其余方法则合并为中危告警。此检查纯粹关于声明——Allow中列出的方法可能在你的服务器上执行也可能不执行，但将其列出会鼓励攻击者进行探测。
为什么重要
TRACE是最严重的。它将完整的请求——包括所有请求头——原样回显给调用者。在某些代理配置或旧技术栈中，如果凭证或会话Cookie作为请求头传递，这种回显可能通过跨站追踪（XST）将这些值暴露给页面中的脚本。现代浏览器会阻止XHR/fetch中的TRACE请求，但代理和负载均衡器可能不会。TRACE在生产环境中没有合法用途：应完全禁用。
PUT、DELETE、PATCH和CONNECT的危险在于，声明它们会诱导攻击者进行测试。对可写路径发送PUT请求可能会在服务器上上传任意文件——WebDAV服务器是典型案例。未经认证的DELETE可能允许调用者删除资源。即使这些方法都经过应用层授权验证是安全的，将它们放在Allow头中也会缩小攻击者的探测范围。
如何修复
在server块级别屏蔽TRACE，并对应用实际使用的方法列表之外的所有方法返回405。
server {
# Reject TRACE completely
if ($request_method = TRACE) {
return 405;
}
location / {
limit_except GET HEAD POST OPTIONS {
deny all;
}
# ... your proxy_pass or root ...
}
}在Express中添加一个中间件，拒绝allowlist之外的所有方法。在Next.js Route Handler中，只导出你需要处理的方法对应的函数——框架会自动对其他方法返回405。
// Express: block anything outside the allowlist early
import express from "express";
const app = express();
app.use((req, res, next) => {
const allowed = new Set(["GET", "HEAD", "POST", "OPTIONS"]);
if (!allowed.has(req.method)) {
res.set("Allow", [...allowed].join(", "));
return res.status(405).json({ error: "Method Not Allowed" });
}
next();
});
// Next.js Route Handler — only exported functions are reachable
// (no DELETE export → Next.js returns 405 automatically)
export async function GET(request: Request) {
return Response.json({ ok: true });
}
// export async function DELETE(...) — don't export this unless you need it服务器更新完成后，发送OPTIONS请求确认Allow响应头中不再包含危险方法。
curl -sI -X OPTIONS https://example.com/ | grep -i allow
# Expected: Allow: GET, HEAD, POST, OPTIONS
# If TRACE, PUT, DELETE, PATCH, or CONNECT appear, the restriction didn't land.常见问题
如果TRACE已经被屏蔽，AppSafe为什么还会告警？
AppSafe读取OPTIONS响应中的Allow请求头——它标记的是服务器声明支持的方法，而非实际执行的方法。服务器可能在Allow头中声称支持TRACE，同时在防火墙规则中屏蔽了该方法。从Allow头中移除TRACE才是正确的修复方式，因为这个头本身就是攻击者阅读的信号。
在Allow头中声明PUT，意味着我的服务器容易受到文件上传攻击吗？
不一定——PUT可能需要身份验证，可能路由到拒绝它的处理器，或者根本不执行任何操作。风险在于它会诱导测试。如果你的应用不需要未经认证的调用者使用PUT，请从Allow响应中删除它。
AppSafe如何检测这个问题？
AppSafe向你网站的根URL发送HTTP OPTIONS请求，读取Allow和Access-Control-Allow-Methods响应头。如果发现TRACE、PUT、PATCH、DELETE或CONNECT，就会报告该发现。TRACE标记为高危；其余标记为中危。