Verificador de Métodos HTTP

Prueba qué métodos HTTP están habilitados en una URL (GET, HEAD, POST, PUT, DELETE, PATCH, TRACE). Marca métodos peligrosos como TRACE (XST) y PUT/DELETE innecesarios. Calificación A-F.

Cómo usar Verificador de Métodos HTTP

  1. 1Ingresa la URL para probar los métodos HTTP permitidos.
  2. 2La herramienta envía una solicitud OPTIONS y prueba verbos HTTP clave.
  3. 3Los resultados muestran el estado permitido/rechazado para cada método con niveles de riesgo.
  4. 4Revisa los métodos peligrosos (TRACE, PUT, DELETE) y recomendaciones.
ZenovayAnalytics

Analytics sin ningún aviso de cookies.

  • Seguimiento de visitantes en tiempo real
  • Privacidad primero, sin aviso de cookies
  • Configurado en dos minutos
Descubre Zenovay

Preguntas frecuentes

¿Qué métodos HTTP son riesgos de seguridad?
TRACE es el más peligroso: habilita los ataques Cross-Site Tracing (XST) que pueden robar cookies incluso cuando HttpOnly está establecido, explotando la reflexión TRACE con un payload XSS malicioso. PUT y DELETE son peligrosos si no están restringidos, ya que pueden permitir a los atacantes cargar o eliminar archivos. CONNECT puede usarse para crear túneles proxy que eludan los cortafuegos. Estos métodos deben deshabilitarse explícitamente a menos que su aplicación los requiera específicamente.
¿Por qué responde mi servidor a PUT/DELETE si no es realmente explotable?
Una respuesta 200/204 a PUT o DELETE no significa necesariamente que un atacante pueda sobrescribir archivos: la autenticación, el middleware de autorización y el enrutamiento de la aplicación pueden seguir bloqueando las acciones no autorizadas. Sin embargo, la exposición de estos métodos indica que su servidor no los está restringiendo a nivel HTTP. La mejor práctica es deshabilitarlos a nivel del servidor web/balanceador de carga a menos que sean explícitamente necesarios (p. ej., APIs REST).
¿Qué es Cross-Site Tracing (XST) y por qué es peligroso TRACE?
XST es un ataque en el que TRACE refleja todo, incluida la cabecera Authorization y las cookies. Combinado con una vulnerabilidad Cross-Site Scripting (XSS), un atacante puede usar JavaScript para enviar una solicitud TRACE y leer las cookies reflejadas, eludiendo el indicador HttpOnly que normalmente impide que JavaScript lea las cookies. OWASP recomienda deshabilitar TRACE en todos los servidores de producción. En Apache: añada «TraceEnable Off». En Nginx: use «if ($request_method = TRACE) { return 405; }».
¿Qué es la cabecera Allow y cómo se relaciona con esta prueba?
La cabecera Allow en una respuesta HTTP (normalmente de una solicitud OPTIONS) enumera los métodos HTTP que el servidor admite para un recurso. Si se devuelve una cabecera Allow, esta herramienta la usa como guía pero aun así envía solicitudes de sondeo para verificar el comportamiento real: algunos servidores anuncian menos métodos de los que admiten. Si no se devuelve cabecera Allow, se sondean directamente todos los métodos del conjunto de pruebas.
¿Cómo debo deshabilitar TRACE en los servidores web más comunes?
Apache: añada «TraceEnable off» en httpd.conf o .htaccess. Nginx: añada «if ($request_method = TRACE) { return 405; }» en el bloque server. IIS: use el módulo Request Filtering para bloquear el verbo TRACE. Node.js/Express: añada middleware para rechazar solicitudes TRACE antes de los manejadores de rutas. Balanceadores de carga (Cloudflare, AWS ALB): configure reglas WAF personalizadas para bloquear TRACE. La mayoría de los CDN modernos bloquean TRACE automáticamente.