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
- 1Ingresa la URL para probar los métodos HTTP permitidos.
- 2La herramienta envía una solicitud OPTIONS y prueba verbos HTTP clave.
- 3Los resultados muestran el estado permitido/rechazado para cada método con niveles de riesgo.
- 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
Herramientas relacionadas
Generador de Contraseñas
Genera contraseñas fuertes y aleatorias con longitud, caracteres y complejidad personalizables.Verificador de Fortaleza de Contraseña
Verifica qué tan fuerte es tu contraseña. Obtén un tiempo estimado de descifrado y sugerencias de mejora.Generador HMAC
Genera firmas HMAC usando SHA-256, SHA-384 o SHA-512 con la API Web Crypto.Cifrado/Descifrado AES
Cifra y descifra texto usando AES-GCM con derivación de clave PBKDF2. Se ejecuta completamente en tu navegador.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.