Checklist de Endurecimiento de Seguridad de WordPress para 2026

La idea clave: el endurecimiento de WordPress no es una sola corrección, sino una checklist por capas que abarca control de acceso, higiene del software, configuración a nivel de servidor, protecciones de red y monitorización continua — cada capa cierra una categoría de riesgo distinta, y saltarse una deja un hueco que las demás no cubren.

Por qué una checklist, no una sola corrección

Cubrimos las vulnerabilidades específicas que realmente comprometen los sitios WordPress — plugins desactualizados, credenciales débiles, inyección SQL, XSS, abuso de XML-RPC — en nuestra guía de vulnerabilidades comunes de WordPress. El endurecimiento es la contraparte proactiva: un conjunto estructurado de decisiones de configuración que reduce la superficie de ataque antes de que cualquier vulnerabilidad específica entre siquiera en juego, organizado aquí por capas para que nada se pase por alto.

Endurecimiento del control de acceso

• Exige autenticación de dos factores para cada cuenta con acceso de publicación o administrador, no solo el administrador principal.
• Aplica roles de privilegio mínimo — dale a cada usuario (y a cada cliente, si el sitio lo gestiona una agencia) el rol de WordPress más bajo que le permita hacer su trabajo real, en lugar de convertir a todos en Administrador por defecto.
• Elimina las cuentas sin usar inmediatamente cuando termina una relación con un miembro del equipo o un cliente, en lugar de dejar una cuenta inactiva con acceso permanente.
• Limita los intentos de inicio de sesión para ralentizar las herramientas automatizadas de fuerza bruta dirigidas a wp-login.php.
• Renombra o restringe el nombre de usuario "admin" por defecto si todavía se usa, ya que es el primer nombre de usuario que prueban los ataques automatizados.

Higiene del núcleo, plugins y temas

• Activa las actualizaciones automáticas para el núcleo de WordPress, los plugins y los temas siempre que la actualización conlleve poco riesgo de regresión, y prueba el resto en una copia de staging antes de subirlo a producción.
• Audita los plugins instalados cada trimestre, eliminando todo lo que no se use activamente — un plugin inactivo con una vulnerabilidad conocida sigue siendo explotable en algunas cadenas de ataque incluso desactivado.
• Revisa el historial de vulnerabilidades y la actividad de mantenimiento de un plugin antes de instalarlo, prefiriendo los plugins activamente mantenidos con un historial de divulgación limpio frente a los abandonados.

Endurecimiento a nivel de servidor y archivos

• Configura los permisos en 644 para archivos y 755 para directorios, según la propia documentación de endurecimiento de WordPress, con wp-config.php idealmente aún más restringido ya que contiene directamente las credenciales de la base de datos.
• Desactiva la edición de archivos desde wp-admin añadiendo define('DISALLOW_FILE_EDIT', true); a wp-config.php, lo que elimina el editor integrado de temas/plugins que le da a un atacante con acceso de administrador una vía directa para ejecutar código.
• Desactiva el listado de directorios en el servidor para que una carpeta mal configurada no exponga un listado de archivos en bruto a cualquiera que lo solicite directamente.
• Cambia el prefijo de tabla de base de datos por defecto (wp_) durante la instalación o mediante una herramienta de migración, eliminando una suposición en la que se basan algunos intentos automatizados de inyección SQL.
• Desactiva XML-RPC a menos que un plugin específico (más comúnmente Jetpack) o una app móvil lo requiera activamente.

Protecciones a nivel de red

• Exige HTTPS en todo el sitio, redirigiendo todo el tráfico HTTP, ya que una conexión sin cifrar expone las credenciales de inicio de sesión y las cookies de sesión a cualquiera en la misma red.
• Añade un cortafuegos de aplicaciones web (WAF), ya sea mediante un servicio a nivel de CDN o un plugin de seguridad, para bloquear patrones de ataque conocidos antes de que lleguen a WordPress.
• Configura cabeceras de seguridad — Content-Security-Policy, X-Frame-Options y Strict-Transport-Security — que la mayoría de los CDN y algunos plugins de seguridad pueden aplicar sin tocar el propio código de WordPress.

Monitorización, registro y copias de seguridad

• Activa la monitorización de integridad de archivos para que un cambio inesperado en un archivo del núcleo o un archivo desconocido que aparezca en wp-content dispare una alerta en lugar de pasar desapercibido.
• Programa escaneos de malware regulares, usando un plugin de seguridad o un servicio de escaneo externo, en lugar de comprobar solo cuando algo ya parece ir mal.
• Mantén copias de seguridad automatizadas y externas con una frecuencia que se ajuste a la frecuencia real de cambios del sitio, y prueba periódicamente que una copia de seguridad realmente se restaura en lugar de asumir que funciona.
• Suscríbete a un feed de divulgación de vulnerabilidades como WPScan o Patchstack para que una vulnerabilidad de plugin recién divulgada se conozca en horas, no se descubra tras su explotación.

Checklist completa de un vistazo

El aspecto de cumplimiento: el endurecimiento no es solo un extra de seguridad

Para las agencias y empresas que operan en la UE, las medidas de endurecimiento se solapan cada vez más con obligaciones regulatorias en lugar de ser una simple buena práctica opcional. La Ley de Ciberresiliencia de la UE exige a los fabricantes de productos con elementos digitales — lo que se extiende a los plugins y temas comerciales de WordPress bajo ciertas condiciones — cumplir requisitos básicos de ciberseguridad y gestionar la divulgación de vulnerabilidades de forma responsable durante toda la vida de un producto, no solo en el lanzamiento.

Los pasos técnicos de endurecimiento anteriores (actualizaciones, control de acceso, monitorización de vulnerabilidades) respaldan directamente el lado de seguridad de esa obligación, aunque el cumplimiento completo también exige documentación aparte — una política de divulgación de vulnerabilidades, una lista de materiales de software (SBOM) y registros de conformidad — que el endurecimiento por sí solo no produce. Este es precisamente el hueco que nuestro plugin Erdo CRA Compliance está diseñado para ayudar a cubrir: escanear un sitio según los requisitos de la CRA, el RGPD y NIS2, y generar la documentación que una checklist de endurecimiento no cubre por sí sola.

Errores comunes de endurecimiento

• Tratar el endurecimiento como una tarea de configuración puntual en lugar de una revisión recurrente, dejando que las cuentas de usuario y las listas de plugins se desvíen de un estado seguro con el paso de los meses.
• Instalar un plugin de seguridad y considerar la checklist completada, cuando los permisos de archivo a nivel de servidor y las decisiones de control de acceso todavía necesitan tratarse de forma independiente.
• Endurecer directamente el sitio en producción para cambios como desactivar la edición de archivos o restringir permisos, sin probar antes en staging por si un plugin depende de la funcionalidad desactivada.
• No probar nunca que las copias de seguridad realmente se restauran, descubriendo una copia corrupta o incompleta solo durante un incidente real.
• Aplicar todos los pasos de endurecimiento excepto las actualizaciones, cuando el software desactualizado sigue siendo el punto de entrada más explotado sin importar lo endurecido que esté todo lo demás.

Para terminar

En resumen, el endurecimiento de WordPress funciona como una checklist por capas en lugar de una acción única — el control de acceso, la higiene del software, la configuración del servidor, la protección de red y la monitorización continua cierran cada uno una categoría de riesgo distinta, y para los sitios orientados a la UE, varios de estos pasos ahora sirven también como base para el cumplimiento normativo en lugar de ser una simple buena práctica opcional. Revisar la lista completa cada trimestre, en lugar de configurarla una vez y asumir que se mantiene, es lo que hace que un sitio endurecido siga realmente endurecido con el paso del tiempo.