Si has realizado un escaneo de seguridad o una auditoría a tu sitio web WordPress recientemente, es posible que te hayas encontrado con una alerta de «Criticidad Baja» pero molesta:
Métodos HTTP Inseguros
Descripción: Se detectaron instancias donde el servidor responde a métodos HTTP que no suelen ser necesarios para una web pública, como PUT y DELETE.
Aunque a menudo se marca como riesgo bajo, dejar estos métodos abiertos puede dar pistas a los atacantes o, en configuraciones de servidor incorrectas, permitirles modificar o borrar archivos. En este artículo, te explicaré qué son y cómo bloquearlos correctamente sin romper tu sitio.
¿Qué son los métodos PUT, DELETE, TRACE y TRACK?
Cuando navegas por internet, tu navegador y el servidor «hablan» usando verbos (métodos):
- GET: «Dame esta página» (lo usas al leer esto).
- POST: «Toma estos datos» (lo usas al enviar un formulario).
Sin embargo, existen otros métodos diseñados para la gestión de archivos y depuración:
- PUT: Sube o reemplaza un archivo en el servidor.
- DELETE: Borra un archivo del servidor.
- TRACE/TRACK: Métodos de diagnóstico que pueden ser usados para robar cookies (ataques XST).
En una web pública normal, tus visitantes nunca deberían necesitar permiso para borrar (DELETE) o subir (PUT) archivos directamente. Por eso debemos bloquearlos.
La Solución: ¿PHP o .htaccess?
Podríamos intentar bloquear esto desde el archivo functions.php de nuestro tema. Sin embargo, esa no es la mejor práctica por dos razones:
- Rendimiento: Si lo hacemos en PHP, la petición insegura tiene que llegar al servidor, cargar WordPress, cargar la base de datos y luego ser rechazada. Es un gasto de recursos innecesario.
- Seguridad: Es mejor detener la amenaza en la «puerta de entrada» (el servidor Apache) antes de que entre a la «casa» (WordPress).
Por eso, la solución correcta es usar el archivo .htaccess.
El Código Correcto (Cuidado con Gutenberg)
Aquí es donde muchos cometen un error. Si bloqueas PUT y DELETE globalmente, romperás el editor de bloques de WordPress (Gutenberg) y muchas funciones de la API REST, ya que WordPress usa estos métodos internamente para guardar borradores o borrar entradas.
Para arreglar la vulnerabilidad manteniendo tu WordPress funcional, añade este código al principio de tu archivo .htaccess:
# ----------------------------------------------------------------------
# SEGURIDAD: Bloquear Métodos HTTP Inseguros
# ----------------------------------------------------------------------
<IfModule mod_rewrite.c>
RewriteEngine On
# 1. Detectar métodos inseguros
RewriteCond %{REQUEST_METHOD} ^(PUT|DELETE|TRACE|TRACK|CONNECT) [NC]
# 2. EXCEPCIÓN: Permitir REST API de WordPress (necesario para Gutenberg)
RewriteCond %{REQUEST_URI} !^/wp-json/ [NC]
# 3. EXCEPCIÓN: Permitir Panel de Administración y AJAX
RewriteCond %{REQUEST_URI} !^/wp-admin/ [NC]
# 4. Bloquear todo lo demás con error 403 Forbidden
RewriteRule .* - [F]
</IfModule>Explicación del código:
- Línea 1: Activamos el motor de reescritura.
- Línea 2: Le decimos al servidor: «Si alguien intenta usar PUT, DELETE, TRACE, TRACK o CONNECT…»
- Línea 3 y 4 (La clave): «…PERO la dirección NO es la API de WordPress (/wp-json/) NI el panel de administración (/wp-admin/)…»
- Línea 5: «…Entonces prohíbe la entrada (Flag [F]).»
Con este pequeño fragmento de código, has logrado dos cosas:
- Has satisfecho a las herramientas de auditoría de seguridad, protegiendo el frontend de tu web.
- Has mantenido intacta la funcionalidad de WordPress permitiendo que el administrador siga trabajando con normalidad.
Recuerda siempre hacer una copia de seguridad de tu archivo .htaccess antes de editarlo. ¡La seguridad web se trata de encontrar el equilibrio entre protección y funcionalidad!