En casi cualquier instalación de WordPress sobre un servidor Apache existe un archivo, oculto por defecto y sin extensión visible más allá del punto inicial, que controla silenciosamente cómo se comporta el servidor ante cada petición que recibe. Ese archivo es .htaccess (hypertext access): un fichero de configuración que permite aplicar reglas a nivel de directorio sin necesidad de tocar la configuración global del servidor, y que en WordPress se ha convertido, además, en una de las primeras líneas de defensa contra ataques automatizados.
Qué hace exactamente, más allá de las URLs «amigables»
La mayoría de usuarios de WordPress solo conocen el .htaccess por su papel en los enlaces permanentes: es el archivo que reescribe URLs como «carloscebrian.es/?p=123» en algo legible como «carloscebrian.es/glosario/htaccess», gracias al módulo mod_rewrite de Apache. Pero su función va mucho más allá: puede bloquear el acceso a archivos y carpetas concretas, forzar HTTPS, limitar quién puede acceder a según qué recursos, controlar la caché del navegador, y, de forma crítica para la seguridad, cerrar puertas de entrada que los atacantes automatizados prueban de forma constante y sistemática en cualquier web con WordPress.
Por qué WordPress es un objetivo tan atractivo para bots de ataque
Al ser, con diferencia, el CMS más usado del mundo, WordPress tiene una estructura de archivos y carpetas extremadamente predecible: cualquier bot sabe de antemano que existe un wp-login.php, un wp-config.php, una carpeta /wp-content/uploads/. Esto convierte a millones de webs WordPress en un blanco enorme y homogéneo, donde merece la pena a gran escala escanear automáticamente rutas conocidas en busca de configuraciones descuidadas, sin necesidad de dirigirse a ningún sitio en concreto.
Las rutas y archivos que los bots prueban de forma constante
- wp-config.php: contiene las credenciales de la base de datos en texto plano; si un servidor mal configurado lo sirve como texto en lugar de ejecutarlo como PHP, expone directamente usuario y contraseña de la base de datos completa.
- xmlrpc.php: una interfaz antigua, pensada originalmente para publicar desde apps externas, que se ha convertido en una de las vías más habituales para ataques de fuerza bruta y de amplificación DDoS, ya que permite probar cientos de combinaciones de usuario y contraseña en una sola petición.
- wp-login.php: el objetivo directo de ataques de fuerza bruta, donde bots prueban miles de combinaciones de usuario y contraseña de forma automatizada hasta encontrar una que funcione.
- /wp-content/uploads/ ejecutando PHP: esta carpeta debería servir solo imágenes y documentos, nunca ejecutar código; si un atacante consigue subir un archivo PHP malicioso ahí (a través de un plugin vulnerable, por ejemplo) y el servidor lo ejecuta, tiene control remoto sobre la web.
- readme.html y license.txt: archivos que revelan la versión exacta de WordPress instalada, información que un atacante usa para buscar vulnerabilidades conocidas de esa versión concreta.
- wp-admin/install.php: si queda accesible tras la instalación inicial, puede permitir reinstalar o secuestrar la configuración del sitio.
- /.git/ y /.env: carpetas y archivos que nunca deberían estar accesibles públicamente, pero que aparecen expuestos quirúrgicamente en instalaciones descuidadas, revelando credenciales, claves de API o el historial completo del código fuente.
- wp-json/wp/v2/users: un endpoint de la API REST de WordPress que, sin restricción, permite enumerar los nombres de usuario reales del sitio, información previa que facilita después un ataque de fuerza bruta dirigido.
- ?author=1, ?author=2…: una forma clásica de enumeración de usuarios, probando IDs numéricos para descubrir qué nombres de usuario existen realmente en el sitio.
- Archivos de backup sueltos (.sql, .zip, .bak): copias de seguridad olvidadas en la raíz del servidor, accesibles públicamente si nadie las ha protegido, que pueden contener la base de datos completa del sitio.
- wp-content/debug.log: si el modo debug de WordPress queda activo en producción, este archivo puede acumular información sensible sobre errores internos del sitio, visible para cualquiera que conozca la ruta.
Cómo se bloquean estas rutas desde el propio .htaccess
Reglas como <Files wp-config.php> Order allow,deny / Deny from all </Files> impiden el acceso directo a ese archivo concreto. Bloquear la ejecución de PHP dentro de /wp-content/uploads/ mediante una regla específica de mod_rewrite o una directiva php_flag engine off en un .htaccess propio dentro de esa carpeta neutraliza uno de los vectores de ataque más habituales tras la subida de un archivo malicioso. Desactivar xmlrpc.php por completo, si no se usa ninguna app externa que dependa de él, elimina de raíz uno de los objetivos más escaneados por bots. Y restringir el acceso a archivos como readme.html o a carpetas como .git, devolviendo un error 403 ante cualquier intento de acceso, cierra puertas que, de otro modo, quedan abiertas de par en par sin ningún motivo real.
Por qué esto no sustituye una estrategia de seguridad completa
El .htaccess es una capa de protección más, no la única ni la definitiva: conviene combinarlo con actualizaciones constantes del núcleo, temas y plugins, contraseñas robustas, autenticación en dos pasos, y un plugin de seguridad que monitorice intentos de acceso sospechosos. Para un repaso más completo de por qué WordPress necesita esta atención constante y qué otras medidas conviene aplicar, puede consultarse este artículo sobre por qué WordPress no es seguro por defecto.
Un matiz técnico que conviene recordar
El archivo .htaccess solo funciona en servidores Apache (o compatibles, como LiteSpeed); en servidores Nginx, las mismas reglas deben aplicarse de otra forma, directamente en la configuración del servidor, ya que Nginx no lee archivos .htaccess por diseño. Antes de aplicar cualquier regla de bloqueo, conviene además hacer una copia de seguridad del archivo original: un error de sintaxis en el .htaccess puede dejar toda la web inaccesible de inmediato, mostrando un error 500 hasta que se corrija.