Métodos HTTP perigosos: como TRACE, PUT e DELETE são anunciados
Servidores HTTP podem anunciar quais métodos aceitam respondendo a uma requisição OPTIONS. Quando essa lista inclui métodos perigosos — TRACE, PUT, DELETE, PATCH ou CONNECT — que não são necessários em produção, você entrega aos atacantes um mapa de pontos de entrada potenciais. O AppSafe envia uma requisição OPTIONS para a URL raiz do seu site e sinaliza qualquer método perigoso nos cabeçalhos Allow ou Access-Control-Allow-Methods.
O que é
Qualquer servidor HTTP pode responder a uma requisição OPTIONS com um cabeçalho Allow listando os métodos que aceita: GET, POST, HEAD, OPTIONS e o que mais suportar. Alguns frameworks e proxies reversos adicionam Access-Control-Allow-Methods à mesma resposta. Nenhum cabeçalho é obrigatório, mas quando presentes indicam a qualquer cliente exatamente quais verbos tentar.
O AppSafe envia uma requisição OPTIONS para sua origem e verifica ambos os cabeçalhos em busca de métodos em uma lista de risco: TRACE, PUT, PATCH, DELETE e CONNECT. TRACE recebe seu próprio achado de alta severidade; os demais são agrupados em severidade média. A verificação é sobre anúncio — um método listado no Allow pode ou não fazer algo no seu servidor, mas listá-lo encoraja a exploração.
Por que importa
TRACE é o mais grave. Ele ecoa toda a requisição — incluindo todos os cabeçalhos — de volta ao chamador. Em ambientes onde credenciais ou cookies de sessão são transmitidos como cabeçalhos, esse eco pode expor esses valores a um script na página via cross-site tracing (XST). Navegadores modernos bloqueiam TRACE via XHR/fetch, mas proxies e balanceadores de carga podem não bloquear. TRACE não tem uso legítimo em produção: desative-o completamente.
PUT, DELETE, PATCH e CONNECT importam porque anunciá-los convida a testes. Um PUT em um caminho gravável pode depositar arquivos arbitrários no servidor — servidores WebDAV são o exemplo clássico. Um DELETE sem autenticação pode permitir que chamadores removam recursos. Mesmo quando esses métodos passam pela lógica de autorização da sua aplicação, tê-los no cabeçalho Allow concentra a lista de sondagem do atacante.
Como corrigir
Bloqueie TRACE no nível do bloco server e retorne 405 para qualquer método fora da lista curta que seu app realmente usa.
server {
# Reject TRACE completely
if ($request_method = TRACE) {
return 405;
}
location / {
limit_except GET HEAD POST OPTIONS {
deny all;
}
# ... your proxy_pass or root ...
}
}No Express, adicione um middleware que rejeite qualquer método não incluído na lista de permitidos. Nos Route Handlers do Next.js, exporte apenas as funções para os métodos que você trata — o framework retorna 405 automaticamente para o restante.
// 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 itApós atualizar o servidor, confirme que o cabeçalho Allow não lista mais os métodos perigosos.
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.FAQ
Se TRACE está bloqueado, por que o AppSafe ainda sinaliza?
O AppSafe lê o cabeçalho Allow de uma resposta OPTIONS — ele sinaliza o que o servidor anuncia, não o que realmente executa. Um servidor pode declarar suporte a TRACE no cabeçalho Allow enquanto bloqueia o método em uma regra de firewall. Remover TRACE do cabeçalho Allow é a correção correta porque o próprio cabeçalho é o sinal que os atacantes leem.
Anunciar PUT no cabeçalho Allow significa que meu servidor é vulnerável a upload de arquivos?
Não necessariamente — PUT pode exigir autenticação, rotear para um handler que o rejeita, ou não fazer nada. O risco é que convida a testes. Se seu app nunca precisa de PUT de chamadores não autenticados, remova-o da resposta Allow.
Como o AppSafe detecta isso?
O AppSafe envia uma requisição HTTP OPTIONS para a URL raiz do seu site e lê os cabeçalhos Allow e Access-Control-Allow-Methods. Se TRACE, PUT, PATCH, DELETE ou CONNECT aparecerem, o achado é reportado. TRACE é sinalizado com severidade alta; os demais com severidade média.
Seu app está afetado?
O AppSafe verifica isso e dezenas de outros problemas em um único escaneamento grátis.
Escanear meu app grátisGuias relacionados
CORS mal configurado: as armadilhas do curinga e do reflexo
Permita toda origem e qualquer site poderá ler sua API.
Páginas de erro detalhadas e stack traces em produção
Um stack trace mostra ao atacante exatamente onde mirar.
Introspecção pública do GraphQL: por que é um problema e como desativá-la
Uma única query retorna o seu schema inteiro. Desative em produção.
Índices de diretório abertos: quando o seu servidor de arquivos lista tudo
Um servidor de arquivos que lista o próprio conteúdo dá aos atacantes um inventário de graça.