Un WordPress puede cargar rápido y verse impecable mientras una contraseña reutilizada o un plugin abandonado deja la puerta abierta. Para securizar WordPress de forma sensata hay que combinar actualizaciones, control de accesos, servidor, copias y comprobaciones periódicas, no acumular plugins de seguridad sin criterio. Aquí explico un proceso práctico, con mentalidad de hacking ético, para reducir riesgos y saber qué hacer si algo falla.
Una protección eficaz nace de varias capas coordinadas
- Actualizaciones del núcleo, plugins, temas y PHP reducen la exposición a vulnerabilidades conocidas.
- 2FA y contraseñas únicas protegen el acceso incluso cuando una clave acaba filtrada.
- Copias externas probadas permiten recuperar la web sin pagar un rescate ni improvisar.
- Un WAF y límites de acceso frenan fuerza bruta, bots y tráfico malicioso antes de llegar a WordPress.
- Las auditorías autorizadas descubren fallos reales sin poner en peligro la web de producción.
Qué suele poner en riesgo a un sitio WordPress
WordPress no se vuelve inseguro por el simple hecho de ser popular. El problema suele aparecer en el ecosistema que lo rodea, especialmente plugins vulnerables, temas sin mantener y credenciales débiles. Un complemento pequeño puede tener acceso a la base de datos, al sistema de archivos o a las cuentas de administración.
En una revisión básica, yo empezaría por hacer un inventario completo. Hay que saber qué versión del núcleo está instalada, qué plugins están activos, quién tiene permisos de administrador, qué servicios externos se conectan y qué software ejecuta el servidor.
- Elimina plugins y temas que no se utilicen. Desactivarlos no siempre basta, porque sus archivos siguen presentes.
- No instales software “nulled” o descargado de repositorios dudosos. Puede incluir puertas traseras antes de llegar a tu servidor.
- Comprueba los usuarios y borra cuentas antiguas, duplicadas o con permisos excesivos.
- Revisa las integraciones mediante API, FTP, SSH, panel de hosting y herramientas de publicación remota.
- Consulta Herramientas > Salud del sitio para detectar configuraciones críticas y problemas de actualización.
Una tienda online, un medio digital y una web corporativa no tienen el mismo nivel de riesgo. En una tienda me preocuparían antes los pagos, los datos personales y la disponibilidad; en un blog pequeño, el robo de la cuenta y la distribución de malware suelen ser las prioridades.
El endurecimiento que aplicaría desde el panel de control
Actualiza con un proceso y no a ciegas
Mantén actualizado el núcleo de WordPress, los plugins, los temas y la versión de PHP. Las actualizaciones de seguridad deben instalarse cuanto antes, pero en una web comercial conviene tener una copia reciente y un entorno de pruebas antes de aplicar cambios importantes.
Las actualizaciones automáticas son útiles para reducir ventanas de exposición, sobre todo en instalaciones sencillas. En proyectos con muchos plugins, personalizaciones o comercio electrónico, prefiero revisar primero la compatibilidad y comprobar después formularios, pagos, búsquedas y páginas críticas.
Protege las cuentas que realmente importan
Usa contraseñas únicas de 20 caracteres o más, guardadas en un gestor de contraseñas. Activa la autenticación multifactor, preferiblemente con una aplicación de códigos o una llave de seguridad, para todas las cuentas administrativas.
También aplicaría el principio de mínimo privilegio. Un redactor necesita el rol de autor o editor, no permisos para instalar plugins. Cuantas menos cuentas tengan acceso total, menor será el impacto de una contraseña robada.
Reduce funciones innecesarias
Desactiva la edición de archivos desde el escritorio añadiendo la constante correspondiente en la configuración de WordPress. Así, una cuenta comprometida no puede modificar directamente un tema desde el panel con la misma facilidad.
El archivo xmlrpc.php merece una revisión, pero no una prohibición automática. Si no utilizas publicación remota, ciertas aplicaciones móviles o integraciones que lo necesiten, puedes bloquearlo; si lo bloqueas sin comprobarlo, podrías romper una función legítima. Cambiar la URL de acceso al panel puede reducir ruido, pero nunca sustituye al 2FA, al límite de intentos y a una buena contraseña.
La seguridad del servidor marca la diferencia
Una web protegida dentro de WordPress sigue estando expuesta si el hosting permite versiones antiguas, paneles sin 2FA o copias accesibles públicamente. Asegúrate de usar HTTPS en todo el sitio, una versión de PHP con soporte y un proveedor que aplique parches de seguridad con rapidez.
La configuración de permisos depende del servidor, pero como referencia habitual los directorios usan permisos 755 y los archivos 644. El archivo de configuración debe quedar especialmente protegido y las credenciales de la base de datos no deberían reutilizarse en otros servicios.
| Capa | Medida recomendable | Qué aporta |
|---|---|---|
| Acceso | 2FA, contraseñas únicas y mínimo privilegio | Reduce el riesgo de toma de cuentas |
| Aplicación | Actualizaciones y plugins de confianza | Cierra fallos conocidos |
| Servidor | HTTPS, PHP mantenido y permisos adecuados | Protege datos y archivos |
| Red | WAF, limitación de peticiones y bloqueo de fuerza bruta | Filtra tráfico malicioso antes de WordPress |
| Recuperación | Copias externas y pruebas de restauración | Permite volver a operar tras un incidente |
Un firewall de aplicaciones web, conocido como WAF, analiza las peticiones HTTP y bloquea patrones asociados a ataques. No es una solución mágica: una mala regla puede bloquear usuarios reales y un WAF no arregla un plugin vulnerable, pero sí añade una capa muy útil frente a bots y ataques automatizados.
Evita instalar tres plugins que hagan exactamente lo mismo. En mi experiencia, la redundancia mal configurada genera conflictos, ralentiza el sitio y dificulta saber qué alerta es importante. Para muchos proyectos basta con un buen sistema de firewall, escaneo, límites de acceso y supervisión desde el hosting.
Copias, registros y respuesta ante un incidente
Una copia de seguridad solo sirve si puedes restaurarla. Para una web activa, usaría copias diarias de la base de datos y de los archivos, conservando varias versiones en un almacenamiento separado. Una tienda con pedidos frecuentes puede necesitar intervalos más cortos, mientras que una web corporativa que apenas cambia contenido puede funcionar con una frecuencia semanal, siempre que el riesgo sea aceptable.
Aplica la regla 3-2-1 cuando el proyecto lo justifique: tres copias, en dos soportes diferentes y al menos una fuera del servidor principal. Haz una restauración de prueba cada pocos meses; una copia que nunca se ha probado es una hipótesis, no un plan de recuperación.
Activa avisos para nuevos administradores, cambios de contraseña, intentos repetidos de acceso, modificaciones de archivos y actualizaciones fallidas. Los registros del servidor y del firewall ayudan a distinguir un error puntual de una intrusión persistente.
Lee también: Mozilla Observatory - ¿Realmente mejora la seguridad web?
Qué hacer si la web ya está comprometida
No empieces borrando archivos al azar. Documenta la hora, los síntomas, las cuentas afectadas y las últimas modificaciones. Después, limita el acceso, conserva una copia para el análisis y evita seguir publicando datos sensibles desde un entorno que ya no controlas.
- Cambia las credenciales del hosting, WordPress, base de datos, FTP, SSH y servicios conectados.
- Revoca sesiones activas, tokens y contraseñas de aplicación.
- Busca usuarios desconocidos, tareas programadas, archivos modificados y código inyectado en plugins o temas.
- Restaura una versión limpia o realiza una limpieza profesional, según la gravedad.
- Actualiza todo y corrige la vía de entrada antes de volver a publicar.
- Después de limpiar el sitio, vuelve a cambiar las contraseñas y revisa los registros.
El error más caro suele ser restaurar una copia infectada y dar el caso por cerrado. Si no se identifica el vector de entrada, el atacante puede volver a utilizarlo en cuestión de horas.
Cómo comprobar la protección con hacking ético
Una auditoría de hacking ético debe tener autorización escrita, alcance definido y límites claros. No es lo mismo revisar una instalación propia que lanzar pruebas contra un hosting compartido, una API de terceros o una web de un cliente sin permiso.
Yo dividiría la revisión en cuatro fases. Primero, reconocimiento controlado de dominios, subdominios y tecnologías expuestas. Después, enumeración de versiones, usuarios visibles, endpoints y componentes. La tercera fase busca configuraciones débiles y vulnerabilidades conocidas, preferiblemente en staging. La última documenta el impacto y propone una corrección verificable.
| Comprobación | Resultado que debería quedar claro |
|---|---|
| Usuarios y roles | No existen cuentas desconocidas ni administradores innecesarios |
| Plugins y temas | Todos tienen origen fiable, soporte y versiones mantenidas |
| Autenticación | Hay 2FA, límites de intentos y sesiones controladas |
| Configuración | No se exponen copias, listados de directorios ni archivos sensibles |
| Recuperación | La restauración funciona y el tiempo de recuperación es conocido |
Para una web pequeña, una revisión trimestral puede ser suficiente si hay actualizaciones frecuentes y monitorización activa. En una tienda, una plataforma con muchos usuarios o una instalación que maneja datos delicados, haría una revisión después de cada cambio importante y al menos una auditoría técnica anual.
El coste depende del alcance. Un servicio gestionado básico puede situarse aproximadamente entre 20 y 80 euros al mes, mientras que una auditoría manual de una instalación sencilla suele partir de varios cientos de euros y aumenta con el número de dominios, usuarios e integraciones. El precio más bajo no compensa si solo entrega un informe automático sin verificar los hallazgos.
La rutina que mantiene segura la instalación con el tiempo
La seguridad no termina al activar un plugin. Cada semana revisaría actualizaciones, usuarios nuevos y alertas; cada mes comprobaría copias, permisos y cambios relevantes; y cada trimestre realizaría una revisión más completa de componentes, integraciones y registros.
Mi criterio es sencillo: menos componentes, mejor mantenidos y con una función clara. Si una medida rompe el sitio, no es una mejora hasta que se prueba correctamente. La protección más realista combina prevención, detección y recuperación, porque ningún WordPress conectado a Internet puede prometer riesgo cero.
Con ese enfoque, securizar la instalación deja de ser una colección de trucos y se convierte en un proceso medible. Sabes qué tienes expuesto, quién puede acceder, cómo detectar una anomalía y cuánto tardarías en recuperar el control.
