Detector de métodos HTTP peligrosos

Cómo funciona esta comprobación

Scanaris envía una petición OPTIONS a la URL analizada, sin seguir redirecciones, y lee dos cabeceras de la respuesta: Allow, con la que un servidor declara qué métodos acepta en esa ruta, y Access-Control-Allow-Methods, la de CORS. Si en cualquiera de las dos aparece TRACE, TRACK, PUT, DELETE o CONNECT, abre un hallazgo de severidad baja con la lista. Es una comprobación conservadora: solo marca lo que el servidor anuncia explícitamente. No envía ningún PUT ni DELETE de prueba, y si el servidor no responde al OPTIONS o no devuelve esas cabeceras, no hay hallazgo.

Por qué importa

Una web normal necesita GET, HEAD, POST y, para CORS, OPTIONS. El resto son métodos con historia. TRACE devuelve la petición tal cual la recibió, cabeceras incluidas; combinado con otro fallo permite leer cookies marcadas como HttpOnly (el ataque se llama Cross-Site Tracing). PUT y DELETE crean, sustituyen o borran recursos: en un servidor de archivos mal configurado, un PUT sube un fichero al directorio público. CONNECT convierte el servidor en un proxy. Que estén habilitados no significa que funcionen sin autenticación, por eso la severidad es baja; pero anunciarlos sin usarlos es superficie de ataque gratis.

Cómo arreglarlo

• Apache: TraceEnable Off en la configuración principal (TRACE viene activado por defecto en versiones antiguas). Para el resto, dentro del Directory o Location de tu web: <LimitExcept GET POST HEAD OPTIONS> Require all denied </LimitExcept>.
• nginx: no implementa TRACE. Para limitar el resto en un bloque location: limit_except GET POST HEAD OPTIONS { deny all; }. Si usas if ($request_method !~ ^(GET|HEAD|POST|OPTIONS)$) { return 405; }, ponlo a nivel de server.
• IIS: el módulo WebDAV es la causa típica de PUT y DELETE anunciados. Desinstálalo si no lo usas, y en web.config limita los verbos con requestFiltering/verbs.
• Express y APIs: si tu API usa PUT o DELETE con autenticación, es legítimo que Access-Control-Allow-Methods los liste; lo que no debe hacer es listarlos en toda la web ni usar *. En el middleware de CORS, pon methods: ['GET', 'POST'] en las rutas públicas y amplía solo donde haga falta.
• Vercel, Netlify, Cloudflare Pages: no anuncian estos métodos por defecto. Si aparece el hallazgo, suele venir de una cabecera CORS que has configurado tú con la lista completa.

Comprueba que está arreglado

curl -si -X OPTIONS https://tudominio.com | grep -iE "^(HTTP|allow|access-control-allow-methods):"
curl -si -X TRACE https://tudominio.com | head -1

En la primera, ni Allow ni Access-Control-Allow-Methods deberían incluir TRACE, TRACK, PUT, DELETE o CONNECT en las rutas públicas. La segunda debe devolver 405 o 403, nunca 200 con tu petición reflejada en el cuerpo.

Preguntas frecuentes

Mi API REST usa PUT y DELETE. ¿Tengo que quitarlos?

No. Lo que importa es que esas rutas exijan autenticación y que la cabecera CORS no los anuncie para todo el dominio ni para cualquier origen. Si el escaneo apunta a la raíz de tu API, el hallazgo de severidad baja puedes darlo por aceptado una vez comprobado eso. La configuración de orígenes la revisa CORS permisivo.

Access-Control-Allow-Methods lista métodos, pero sin Allow. ¿Es lo mismo?

No del todo. Allow describe lo que el servidor acepta; la cabecera CORS describe lo que permite a páginas de otros orígenes. Ambas se leen porque ambas son información que das. Qué significa cada parte de una respuesta CORS lo explica CORS mal configurado.

¿Por qué OPTIONS no se considera peligroso?

Porque es el método con el que el navegador pregunta por CORS antes de ciertas peticiones. Bloquearlo rompe las llamadas entre dominios. Es inofensivo y necesario.