Métodos HTTP peligrosos: cómo se anuncian TRACE, PUT y DELETE
Los servidores HTTP pueden anunciar qué métodos admiten respondiendo a una petición OPTIONS. Cuando esa lista incluye métodos peligrosos —TRACE, PUT, DELETE, PATCH o CONNECT— que no son necesarios en producción, le entregas a los atacantes un mapa de posibles puntos de entrada. AppSafe envía una petición OPTIONS a la URL raíz de tu sitio y marca cualquier método peligroso que encuentre en las cabeceras Allow o Access-Control-Allow-Methods.
Qué es
Cualquier servidor HTTP puede responder a una petición OPTIONS con una cabecera Allow que lista los métodos que acepta: GET, POST, HEAD, OPTIONS, y los que más soporte. Algunos frameworks y proxies inversos añaden Access-Control-Allow-Methods a la misma respuesta. Ninguna cabecera es obligatoria, pero cuando están presentes indican a cualquier cliente exactamente qué verbos intentar.
AppSafe envía una petición OPTIONS a tu origen y comprueba ambas cabeceras buscando métodos en una lista de riesgo: TRACE, PUT, PATCH, DELETE y CONNECT. TRACE recibe su propio hallazgo de severidad alta; los demás se agrupan en severidad media. La comprobación se centra en el anuncio: un método listado en Allow puede o no hacer algo en tu servidor, pero anunciarlo fomenta la exploración.
Por qué importa
TRACE es el más grave. Devuelve la petición completa —incluyendo todas las cabeceras— al emisor. En entornos donde las credenciales o cookies de sesión se transmiten como cabeceras de petición, ese eco podría exponer esos valores a un script en la página mediante cross-site tracing (XST). Los navegadores modernos bloquean TRACE desde XHR/fetch, pero proxies y balanceadores de carga pueden no hacerlo. TRACE no tiene uso legítimo en producción: desactívalo por completo.
PUT, DELETE, PATCH y CONNECT importan porque anunciarlos invita a realizar pruebas. Un PUT que llega a una ruta con escritura habilitada puede depositar archivos arbitrarios en el servidor —los servidores WebDAV son el ejemplo clásico—. Un DELETE sin autenticación puede permitir eliminar recursos. Aunque estos métodos pasen por la lógica de autorización de tu aplicación, tenerlos en la cabecera Allow concentra la lista de pruebas del atacante.
Cómo solucionarlo
Bloquea TRACE a nivel de bloque server y devuelve 405 para cualquier método fuera de la lista corta que tu 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 ...
}
}En Express añade un middleware que rechace cualquier método no incluido en la lista de permitidos. En los Route Handlers de Next.js, exporta solo las funciones para los métodos que gestionas: el framework devuelve 405 automáticamente para el resto.
// 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 itUna vez actualizado el servidor, confirma que la cabecera Allow ya no lista los métodos peligrosos.
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.Preguntas frecuentes
Si TRACE está bloqueado, ¿por qué AppSafe lo sigue marcando?
AppSafe lee la cabecera Allow de una respuesta OPTIONS: marca lo que el servidor anuncia, no lo que realmente ejecuta. Un servidor puede declarar que admite TRACE en su cabecera Allow mientras bloquea el método en una regla de firewall. Eliminar TRACE de la cabecera Allow es la solución correcta porque la cabecera en sí es la señal que leen los atacantes.
¿Anunciar PUT en la cabecera Allow significa que mi servidor es vulnerable a la subida de archivos?
No necesariamente: PUT puede requerir autenticación, enrutarse a un handler que lo rechaza, o no hacer nada en absoluto. El riesgo es que invita a realizar pruebas. Si tu app nunca necesita PUT de clientes no autenticados, elimínalo de la respuesta Allow.
¿Cómo lo detecta AppSafe?
AppSafe envía una petición HTTP OPTIONS a la URL raíz de tu sitio y lee las cabeceras Allow y Access-Control-Allow-Methods. Si aparece TRACE, PUT, PATCH, DELETE o CONNECT, reporta el hallazgo. TRACE se marca con severidad alta; los demás con severidad media.
¿Tu app está afectada?
AppSafe verifica este y docenas de problemas más en un solo escaneo gratis.
Escanear mi app gratisGuías relacionadas
CORS mal configurado: las trampas del comodín y del reflejo
Permite todos los orígenes y cualquier sitio podrá leer tu API.
Páginas de error detalladas y stack traces en producción
Un stack trace le dice al atacante exactamente dónde apuntar.
Introspección pública de GraphQL: por qué es un problema y cómo desactivarla
Una sola consulta devuelve todo tu esquema. Desactívala en producción.
Índices de directorio abiertos: cuando tu servidor de archivos lo lista todo
Un servidor de archivos que lista su contenido regala a los atacantes un inventario.