Seguridad en WordPress: checklist técnico real

Checklist práctico de seguridad en WordPress: capas de protección, configuraciones críticas y criterios técnicos que marcan la diferencia real.

Por qué la seguridad en WordPress necesita un enfoque por capas

Hablar de seguridad en WordPress no es hablar de instalar un plugin y olvidarse. Según datos del informe anual de Sucuri sobre amenazas web, WordPress representó más del 96% de los CMS infectados en sus análisis de sitios comprometidos en 2023. Eso no significa que WordPress sea inseguro por diseño; significa que al ser el CMS más utilizado del mundo (con más del 43% de cuota de mercado), es también el objetivo más frecuente.

El problema real no está en el núcleo de WordPress. La mayoría de las vulnerabilidades explotadas provienen de plugins desactualizados, temas abandonados, configuraciones de servidor permisivas y, sobre todo, de la ausencia de una estrategia de seguridad estructurada. Este artículo no es una lista de plugins recomendados —eso ya lo tienes en decenas de sitios—. Lo que planteo aquí es un checklist técnico organizado por capas, pensado para que evalúes dónde está realmente expuesto tu sitio y qué acciones tienen impacto medible.

Capa 1: Infraestructura y hosting

La primera capa de protección de cualquier instalación WordPress no depende de WordPress en sí, sino del entorno donde se ejecuta. Si el servidor tiene configuraciones laxas, da igual cuántos plugins de seguridad instales encima.

Certificado SSL y HTTPS forzado

Parece básico, pero todavía en 2026 hay sitios WordPress funcionando sin HTTPS o con implementaciones parciales donde ciertos recursos se cargan por HTTP. El certificado SSL cifra la comunicación entre el navegador y el servidor, protege credenciales de login, datos de formularios y cookies de sesión. No es opcional: Google lo marca como factor de ranking desde 2014 y los navegadores modernos muestran advertencias explícitas en sitios sin SSL.

Verifica que tu sitio fuerza HTTPS en todas las URLs. En el archivo .htaccess de Apache, la redirección debería existir. En servidores Nginx, la directiva return 301 https://$host$request_uri; cumple la misma función. Si usas un CDN como Cloudflare, asegúrate de que el modo SSL esté configurado como «Full (strict)» y no como «Flexible», que puede crear bucles de redirección o conexiones sin cifrar entre el CDN y tu origen.

Versión de PHP y configuración del servidor

WordPress recomienda PHP 8.1 o superior. Cada versión de PHP que queda sin soporte activo deja de recibir parches de seguridad. Si tu hosting todavía ejecuta PHP 7.4 (cuyo soporte de seguridad terminó en noviembre de 2022), tienes una brecha estructural que ningún plugin va a cubrir.

Más allá de la versión, hay directivas PHP que afectan directamente a la seguridad de WordPress:

• display_errors = Off en producción — los mensajes de error pueden revelar rutas de archivos y estructura de la base de datos.
• expose_php = Off — evita que las cabeceras HTTP revelen la versión exacta de PHP.
• disable_functions — funciones como exec, shell_exec, system y passthru deberían estar deshabilitadas salvo que un proceso específico las requiera.
• open_basedir — restringe el acceso del script PHP solo al directorio de tu instalación.

Aislamiento de cuentas

En hostings compartidos, pregunta si usan CloudLinux o algún sistema de aislamiento de cuentas (CageFS, por ejemplo). Sin aislamiento, un sitio comprometido en el mismo servidor podría acceder a archivos de tu instalación. En servidores VPS o dedicados, cada sitio debería ejecutarse bajo su propio usuario del sistema operativo, no bajo el mismo www-data genérico.

Capa 2: Configuración del núcleo de WordPress

Una vez que el entorno de servidor es sólido, la siguiente capa de seguridad en WordPress se configura dentro de la propia instalación, principalmente a través de archivos de configuración y ajustes que muchos administradores dejan en sus valores por defecto.

El archivo wp-config.php

Este archivo es el corazón de la configuración de WordPress. Contiene las credenciales de la base de datos, las claves de autenticación y constantes que controlan el comportamiento del sistema. Algunos ajustes críticos:

• define('DISALLOW_FILE_EDIT', true); — desactiva el editor de archivos del panel de administración. Si un atacante consigue acceso al backend, no podrá modificar directamente el código de temas o plugins desde el navegador.
• define('DISALLOW_FILE_MODS', true); — va un paso más allá: impide instalar o actualizar plugins y temas desde el panel. Esto obliga a gestionar cambios vía FTP/SSH o mediante un flujo de despliegue controlado. Es restrictivo, pero en entornos de producción estables reduce drásticamente la superficie de ataque.
• define('FORCE_SSL_ADMIN', true); — fuerza HTTPS en el área de administración.
• Las salt keys (claves de seguridad): si nunca las has cambiado desde la instalación original, WordPress ofrece un generador oficial en https://api.wordpress.org/secret-key/1.1/salt/. Cambiarlas invalida todas las sesiones activas, lo cual es una buena práctica periódica.

Además, el propio archivo wp-config.php debería estar protegido. Muévelo un nivel por encima de la raíz web (WordPress lo detecta automáticamente) o, si no es posible, restringe su acceso vía .htaccess con una directiva <Files> que devuelva un 403.

Prefijo de tablas de la base de datos

El prefijo por defecto wp_ facilita ataques de inyección SQL automatizados, porque el atacante ya conoce los nombres de las tablas. Cambiar el prefijo durante la instalación es trivial. Cambiarlo después requiere modificar el valor en wp-config.php, renombrar todas las tablas en la base de datos y actualizar los registros de la tabla de opciones y usermeta que contienen el prefijo. No es un cambio difícil, pero hacerlo mal puede romper el sitio. Lo importante: si estás montando un WordPress nuevo, define un prefijo personalizado desde el minuto cero.

Permisos de archivos y directorios

Los permisos estándar recomendados por la documentación oficial de WordPress son:

• Directorios: 755 (o 750 en entornos más restrictivos).
• Archivos: 644 (o 640).
• wp-config.php: 440 o 400.

El error más común es dar permisos 777 a directorios de subida o a carpetas de plugins para «solucionar» un error de escritura. Eso equivale a dejar la puerta abierta. Si un directorio necesita permisos de escritura, debe ser exclusivamente wp-content/uploads, y aun así con 755, nunca 777.

Capa 3: Gestión de accesos y autenticación

Más de la mitad de los sitios WordPress comprometidos lo son por credenciales débiles o robadas. La gestión de quién accede al panel —y cómo— es una capa de protección que muchas veces se subestima.

Contraseñas y autenticación en dos factores

Las contraseñas deben ser largas (mínimo 16 caracteres), únicas y gestionadas con un gestor de contraseñas. No es suficiente con que el administrador tenga buena contraseña: cada usuario con acceso al panel necesita el mismo nivel de exigencia. WordPress desde la versión 5.6 genera contraseñas seguras por defecto al crear usuarios, pero no impide que el usuario las cambie por algo débil.

La autenticación en dos factores (2FA) añade una capa que hace inútil el robo de contraseñas por sí solo. Plugins como WP 2FA o el módulo 2FA de Wordfence implementan TOTP (Time-based One-Time Password) compatible con aplicaciones como Google Authenticator o Authy. Lo ideal es que el 2FA sea obligatorio al menos para los roles de administrador y editor.

Limitar intentos de login y cambiar la URL de acceso

Los ataques de fuerza bruta contra /wp-login.php son constantes y automatizados. Limitar los intentos de login a 3-5 por dirección IP antes de un bloqueo temporal es una medida efectiva contra bots. Cambiar la URL de acceso (de /wp-login.php a una ruta personalizada) no es seguridad real por sí sola —es seguridad por oscuridad—, pero combinada con otras medidas reduce significativamente el ruido de ataques automatizados y los recursos del servidor consumidos por bots.

Revisión periódica de usuarios

Audita los usuarios registrados en tu instalación al menos una vez al trimestre. Busca cuentas inactivas, usuarios con rol de administrador que no deberían tenerlo, y direcciones de correo que no reconozcas. Los atacantes que consiguen acceso suelen crear una cuenta de administrador silenciosa como puerta trasera persistente. Si encuentras un usuario administrador que no creaste, tienes un problema activo.

Capa 4: Plugins, temas y actualizaciones

Esta capa es la que genera la mayoría de las vulnerabilidades explotadas en WordPress. No porque los plugins sean malos en sí, sino porque la gestión de su ciclo de vida suele ser inexistente.

Criterios para evaluar la seguridad de un plugin

Antes de instalar cualquier plugin, verifica:

• Última actualización: si lleva más de 6 meses sin actualización, cuestiona si sigue mantenido.
• Compatibilidad con tu versión de WordPress: el repositorio oficial lo indica explícitamente.
• Número de instalaciones activas: no es garantía de calidad, pero un plugin con menos de 1.000 instalaciones tiene menos ojos revisando su código.
• Historial de vulnerabilidades: consulta bases de datos como WPScan Vulnerability Database o Patchstack para ver si el plugin ha tenido CVEs recientes y si fueron parcheados con rapidez.
• Reputación del desarrollador: ¿mantiene otros plugins? ¿Responde en los foros de soporte?

Política de actualizaciones

Actualizar todo de golpe sin plan no es buena práctica. Tampoco lo es no actualizar nunca. Una política razonable para proteger WordPress:

1. Activar actualizaciones automáticas menores del core (ya vienen activadas por defecto desde WordPress 5.6).
2. Revisar actualizaciones mayores del core en un entorno de staging antes de aplicar en producción.
3. Actualizar plugins de seguridad de forma prioritaria, idealmente en las primeras 24-48 horas tras la publicación del parche.
4. Eliminar plugins y temas inactivos. Un tema que no usas pero sigue instalado puede contener vulnerabilidades explotables.

Capa 5: Monitorización y respuesta

Las cuatro capas anteriores son preventivas. Esta quinta capa asume que ninguna prevención es perfecta y establece mecanismos para detectar y responder ante incidentes.

Escaneo de malware y monitorización de integridad

Un escáner de malware revisa los archivos de tu instalación buscando código malicioso, shells PHP, redirecciones ocultas y puertas traseras. La monitorización de integridad compara los archivos de tu instalación con las versiones originales del repositorio y te alerta cuando algo cambia sin que tú lo hayas modificado.

Herramientas como Wordfence incluyen ambas funciones. Si prefieres un enfoque a nivel de servidor, herramientas como AIDE o OSSEC monitorizan cambios en archivos del sistema de forma independiente a WordPress.

Copias de seguridad verificadas

Una copia de seguridad que no has probado restaurar es una copia de seguridad que no existe. La estrategia mínima viable:

• Backup completo diario (archivos + base de datos).
• Retención de al menos 30 días de copias.
• Almacenamiento externo al servidor (Amazon S3, Google Cloud Storage, un servidor remoto independiente). Si el servidor se compromete y los backups están en el mismo lugar, los pierdes también.
• Prueba de restauración trimestral en un entorno de staging.

Registro de actividad (audit log)

Un registro de actividad dentro de WordPress documenta quién hizo qué y cuándo: logins, cambios de configuración, instalaciones de plugins, modificaciones de contenido. Si ocurre un incidente, el audit log es lo primero que se revisa para reconstruir la línea temporal del ataque. Plugins como WP Activity Log o Simple History cumplen esta función. Sin este registro, investigar un sitio comprometido es como trabajar a ciegas.

Capa 6: Firewall de aplicaciones web (WAF)

Un WAF (Web Application Firewall) filtra y bloquea peticiones maliciosas antes de que lleguen a tu aplicación. Existen dos modalidades principales para WordPress:

• WAF a nivel de plugin: se ejecuta dentro de la propia instalación WordPress. Ejemplos: Wordfence, NinjaFirewall. Tiene la ventaja de conocer el contexto de WordPress (usuarios logueados, rutas internas), pero consume recursos del servidor porque procesa cada petición.
• WAF a nivel de DNS/CDN: se ejecuta fuera del servidor, como proxy inverso. Ejemplos: Cloudflare WAF, Sucuri Firewall. Filtra el tráfico malicioso antes de que alcance tu servidor, lo que reduce la carga. La desventaja es que necesita que todo el tráfico pase por un tercero.

Ninguna de las dos opciones es universalmente mejor. La elección depende de tu infraestructura, presupuesto y nivel de tráfico. Lo que no es opcional en 2026 es tener alguna forma de WAF. Los ataques automatizados contra WordPress son continuos y un WAF bien configurado bloquea la inmensa mayoría sin intervención manual.

Checklist rápido: evaluación de seguridad WordPress

Usa esta lista para hacer una auditoría rápida del estado de protección de tu sitio WordPress. No es exhaustiva, pero cubre los puntos con mayor impacto:

Errores frecuentes que debilitan la seguridad de un sitio WordPress

Más allá de lo que hay que hacer, conviene tener claro qué errores son los más habituales y los que más consecuencias tienen:

• Confiar solo en un plugin de seguridad: un plugin es una capa, no la estrategia completa. Si el hosting es débil, las contraseñas flojas y no hay backups, el plugin no puede compensar todo eso.
• No tener un plan de respuesta ante incidentes: ¿qué haces si mañana tu sitio aparece redirigiendo a una web de phishing? Si no tienes documentado el proceso (a quién contactar, dónde están los backups, cómo restaurar), perderás horas o días en resolverlo.
• Ignorar la seguridad del correo electrónico asociado: el email del administrador es el vector de recuperación de contraseña. Si esa cuenta de correo no tiene 2FA propio, un atacante puede resetear la contraseña de WordPress sin tocar tu servidor.
• Usar temas o plugins nulled (pirateados): los temas y plugins «gratuitos» descargados de sitios no oficiales son la forma más directa de instalar malware voluntariamente en tu WordPress. No hay excepción a esta regla.

Preguntas frecuentes sobre seguridad en WordPress

¿WordPress es intrínsecamente inseguro?

No. El núcleo de WordPress tiene un equipo de seguridad dedicado y un proceso de revisión riguroso. Las vulnerabilidades explotadas con más frecuencia provienen de plugins y temas de terceros, configuraciones débiles del servidor y errores humanos (contraseñas flojas, falta de actualizaciones). WordPress bien configurado y mantenido es tan seguro como cualquier otro CMS.

¿Cada cuánto debería auditar la seguridad de mi sitio?

Una revisión completa cada trimestre es un buen punto de partida. Las actualizaciones de plugins y core deberían revisarse semanalmente. La monitorización de malware y los backups deben ser automáticos y continuos, no manuales.

¿Necesito un WAF si mi hosting ya tiene protección?

Depende de qué incluya tu hosting. Muchos hostings ofrecen protección básica contra DDoS y filtrado de IPs, pero no un WAF con reglas específicas para WordPress. Si tu hosting no especifica protección a nivel de aplicación (reglas que entienden la estructura de WordPress), añadir un WAF propio es recomendable.

¿Las actualizaciones automáticas son seguras?

Las actualizaciones menores del core (parches de seguridad y correcciones) son seguras en la inmensa mayoría de los casos y deberían estar activadas. Para actualizaciones mayores del core y de plugins, es preferible probar primero en un entorno de staging si tu sitio tiene funcionalidad personalizada que pueda verse afectada.

Proteger un sitio WordPress no requiere conocimientos de ciberseguridad avanzada, pero sí requiere método y constancia. Si necesitas implementar estas capas de protección en un proyecto WordPress con desarrollo a medida o funcionalidad compleja, puedes revisar cómo trabajo estos temas en mi página de servicios.

// Sobre el autor

fernandodomecq

Desarrollador WordPress freelance especializado en WooCommerce, integraciones e IA. Escribo sobre proyectos web, agencias y buenas prácticas técnicas.

Ver todos los artículos →