La seguridad en WordPress no es una casilla que marcar. Es un sistema por capas que debe resistir bots, atacantes oportunistas y algún que otro intento dirigido — y el coste de hacerlo mal ha aumentado. Un sitio corporativo comprometido en 2026 implica exposición al RGPD, pérdida de confianza, semanas de limpieza forense y daños en el SEO que pueden tardar meses en recuperarse.
Esta es la lista de verificación que repaso en cada auditoría que asumo. No es una lista genérica del tipo «instala Wordfence y listo» — son los controles por capas que realmente importan en sitios WordPress y WooCommerce de misión crítica.
1. Capa de servidor y alojamiento
El hardening más sólido de WordPress no sirve de nada si el servidor subyacente es compartido con cientos de otros sitios y el proveedor no los aísla correctamente. Empieza aquí.
Versión de PHP y aislamiento
Utiliza una versión de PHP con soporte activo (8.2 u 8.3 a partir de 2026). Cada versión de retraso implica parches de seguridad no aplicados y peor rendimiento. Si tu proveedor de alojamiento sigue sirviendo PHP 7.4 en 2026, estás pagando por dejadez.
Para sitios corporativos, exige pools de PHP-FPM aislados por sitio, no un pool compartido. Esto evita que un vecino comprometido pueda pivotar hacia tu código o conexión de base de datos.
Firewall de aplicaciones web
Un WAF situado delante de WordPress filtra el ruido — abuso de XML-RPC, intentos de fuerza bruta, firmas de exploits comunes — antes de que las peticiones lleguen a PHP. El WAF gratuito de Cloudflare junto con la limitación de velocidad gestiona el 90 % del volumen; para sitios de mayor riesgo, el plan Pro añade gestión de bots y reglas administradas ajustadas para WordPress.
Los firewalls basados en plugins (Wordfence, Solid Security) se ejecutan dentro de PHP, lo que significa que solo actúan después de que PHP ya se ha cargado. Tienen su lugar — reglas a nivel de aplicación, monitorización de inicios de sesión — pero no son un sustituto de un WAF en el perímetro.
HTTPS y cabeceras
TLS 1.2 como mínimo, idealmente 1.3. Cabecera HSTS con un max-age de al menos 1 año una vez que estés seguro de que el certificado es estable. Las demás cabeceras que deben estar presentes en cada respuesta de un sitio WordPress serio:
X-Content-Type-Options: nosniffX-Frame-Options: SAMEORIGIN(o una CSP adecuada conframe-ancestors)Referrer-Policy: strict-origin-when-cross-originPermissions-Policyrestringida a las APIs que el sitio utiliza realmenteContent-Security-Policy— la más difícil de configurar correctamente, pero la de mayor impacto
2. Núcleo de WordPress
El núcleo es la parte fácil — pero también es donde la mayoría de las historias de «nos hackearon» comienzan en realidad. Casi siempre por actualizaciones retrasadas o una constante mal configurada.
Actualizaciones automáticas para versiones menores y de seguridad
En wp-config.php, establece define( 'WP_AUTO_UPDATE_CORE', 'minor' );. Esto aplica parches de seguridad automáticamente sin arriesgar los cambios disruptivos de una versión mayor. Las actualizaciones de versión mayor permanecen manuales y se prueban en staging.
Deshabilitar la edición de archivos desde el panel de administración
Esta única línea en wp-config.php bloquea el pivote más habitual tras un compromiso: la subida de código malicioso a través de Apariencia → Editor de archivos del tema:
define( 'DISALLOW_FILE_EDIT', true );Combínalo con DISALLOW_FILE_MODS si no necesitas instalar plugins ni temas desde el panel de administración — los cambios de código se gestionan a través de Git de todas formas.
Salts y prefijo de base de datos
Rota las ocho claves de autenticación y salts en wp-config.php al menos una vez al año e inmediatamente después de cualquier compromiso sospechado. Utiliza el generador oficial de WordPress.org. Un prefijo de base de datos personalizado (distinto de wp_) supone un pequeño obstáculo para los intentos automatizados de inyección SQL — configúralo en el momento de la instalación; cambiarlo en un sitio en producción conlleva más riesgos que beneficios.
3. Plugins y temas
Aquí es donde reside la superficie de ataque real. Cada plugin es código que se ejecuta con acceso completo al sistema de archivos y a la base de datos. Un plugin abandonado de un proveedor que desapareció hace dos años es un exploit en potencia.
Auditar y depurar
Una vez por trimestre: lista todos los plugins instalados y hazte tres preguntas por cada uno.
- ¿Se sigue utilizando? (Fíjate en el uso real de la funcionalidad, no en «algún día podría ser útil».)
- ¿Ha sido actualizado en los últimos 12 meses por el proveedor?
- ¿Dispone de una política de divulgación de seguridad publicada?
Si la respuesta a cualquiera de estas preguntas es no, el plugin se reemplaza o se elimina. La proliferación de plugins es el mayor predictor individual de que un sitio WordPress acabe comprometido — por encima de la versión del núcleo, por encima del alojamiento.
Evitar plugins nulled / pirateados
No debería tener que decir esto en 2026, pero sigo encontrándolos en auditorías. Los plugins premium nulled casi siempre vienen con puertas traseras incluidas. Los 99 € que «ahorras» en un año de WPML o en una extensión premium de WooCommerce se convierten en una factura de respuesta a incidentes de cinco cifras.
Restringir XML-RPC y la API REST
XML-RPC es una interfaz heredada que sigue estando habilitada por defecto. A menos que uses Jetpack o un cliente de publicación remota, desactívala por completo a nivel de servidor (un único bloque location en nginx o una regla en .htaccess).
La API REST es más útil, pero su exposición predeterminada de /wp-json/wp/v2/users filtra nombres de usuario a peticiones anónimas. Restringe ese endpoint a peticiones autenticadas con un pequeño filtro rest_authentication_errors.
4. Inicio de sesión y acceso
La mayoría de las brechas comienzan en el formulario de inicio de sesión. Reforzarlo no es opcional.
Autenticación de dos factores para cada cuenta de administrador
2FA basado en TOTP (mediante Wordfence Login Security, Two Factor o un proveedor SSO) en cada cuenta con rol administrator o editor. Sin excepciones, incluida la tuya. Si externalizas el desarrollo, tu colaborador obtiene su propia cuenta con 2FA, no un acceso de administrador compartido.
Renombrar o limitar la tasa de peticiones a /wp-login.php
La seguridad por oscuridad es débil, pero combinada con la limitación de tasa sí reduce considerablemente el tráfico de bots. Puedes mover wp-login.php a una ruta personalizada (WPS Hide Login lo hace de forma limpia) o aplicar un límite de tasa estricto a nivel de WAF: 5 intentos cada 15 minutos por IP es una cifra razonable.
Política de contraseñas seguras aplicada de forma obligatoria
El medidor de fortaleza integrado de WordPress es orientativo, no vinculante. Utiliza un plugin (Password Policy Manager o el incluido en tu suite de seguridad) que bloquee las contraseñas débiles. Mínimo 12 caracteres, debe incluir los cuatro tipos de caracteres y rechazarse contra una lista de contraseñas filtradas conocidas.
5. Sistema de archivos y permisos
Una instalación de WordPress con los permisos correctos limita el alcance del daño ante cualquier compromiso.
- Directorios:
755 - Archivos:
644 wp-config.php:600(legible únicamente por el usuario con el que se ejecuta el servidor web)- Propietario: el usuario de despliegue, no el usuario del servidor web
- Usuario del servidor web: solo lectura en todo excepto en
wp-content/uploads/y las pocas cachés que necesitan acceso de escritura
Deshabilita la ejecución de PHP dentro de wp-content/uploads/ a nivel de servidor. Este es el control defensivo más útil contra el patrón de ataque de «subieron un .php disfrazado de .jpg».
6. Base de datos
La base de datos raramente es el punto de entrada, pero casi siempre es donde se produce el daño: exfiltración de datos, inyección de usuarios administradores, contenido de publicaciones malicioso.
- Usuario de base de datos dedicado por sitio con los privilegios mínimos necesarios (sin
GRANT, sinDROP DATABASE) - Base de datos y servidor web en red privada; sin puerto de base de datos público
- Copias de seguridad cifradas almacenadas fuera del servidor, conservadas durante al menos 30 días
- Restauración probada al menos dos veces al año: una copia de seguridad que nunca has restaurado es una esperanza, no una copia de seguridad
7. Monitorización y respuesta
Tarde o temprano se verá comprometido. La diferencia entre un incidente de 24 horas y un desastre de 6 semanas está en si se entera por su sistema de monitorización o por un cliente.
Monitorización de integridad de archivos
Un análisis diario que compara el sistema de archivos actual con una línea base conocida como correcta. Cualquier archivo del núcleo modificado, cualquier archivo PHP nuevo en wp-content/uploads/, cualquier cambio en .htaccess genera una alerta. Wordfence hace esto; también lo hacen herramientas empresariales como OSSEC.
Monitorización del tiempo de actividad y el comportamiento
Las comprobaciones simples de tiempo de actividad (UptimeRobot, BetterUptime) detectan lo evidente. Más útil aún: la detección de anomalías en el tiempo de respuesta — un sitio que de repente se ralentiza 3× a menudo tiene un criptominero en wp-content/uploads/.
Plan de respuesta documentado
Redactado antes de que lo necesite: quién llama a quién, qué se desconecta, dónde está la última copia de seguridad limpia, cómo es el flujo de notificación del RGPD si se expusieron datos personales. Un documento de una página supera a un plan perfectamente diseñado que jamás leerá en un momento de pánico.
Cómo se ve esto en la práctica
La lista de verificación completa tiene más de 30 controles. La mayoría de los sitios que audito tienen entre 5 y 10 de ellos implementados — los más económicos, más lo que el desarrollador original recordó. Los 20 restantes son donde se concentra la verdadera reducción de riesgo.
La buena noticia: no se necesita un proyecto de seguridad de seis meses para alcanzar un estado defendible. La primera mitad de esta lista — bastionado del servidor, constantes del núcleo, auditoría de plugins, 2FA, permisos de archivos — se completa en dos o tres días de trabajo concentrado. El resto es una rutina trimestral.
Si prefiere no ser usted quien realice todo esto, es exactamente lo que cubre la Auditoría de Ingeniería WordPress — la misma revisión de seguridad entregada como un plan de remediación priorizado.
