Instalar un plugin de seguridad y dar por hecho que ya estás protegido es el error más repetido en WordPress. Un plugin vigila; una auditoría comprueba. Son cosas distintas, y solo la segunda te dice dónde estás realmente expuesto.
La buena noticia es que una auditoría de seguridad, que hace unos años exigía leer decenas de páginas de documentación, hoy se puede hacer con la inteligencia artificial como copiloto en una tarde. La mala es que hay una parte que la IA no debe decidir por ti, y conviene tenerla clara desde el principio.
Qué aporta la IA en una auditoría de seguridad (y qué no)
Conviene ser honesto antes de empezar, porque hay mucha promesa inflada sobre esto.
La IA es muy buena en:
- Leer un listado largo de plugins con sus versiones y decirte cuáles llevan años sin actualizarse.
- Traducir un aviso técnico de vulnerabilidad a un lenguaje que entiendas.
- Revisar un fichero de configuración y señalar líneas sospechosas.
- Priorizar: ordenar veinte hallazgos por riesgo real en lugar de dejarte una lista plana.
- Redactar el informe final para que puedas pasárselo a un cliente o a tu equipo.
La IA no debe hacer:
- Decidir si una vulnerabilidad te afecta. Eso se comprueba contra la base de datos oficial, no se pregunta.
- Confirmar que una web está limpia. Un modelo puede afirmarlo con toda seguridad y estar equivocado.
- Ejecutar cambios en producción. La IA propone, tú aplicas, y siempre con copia de seguridad delante.
Con esa frontera clara, vamos al procedimiento.
Paso 1: levanta el inventario
No puedes auditar lo que no sabes que tienes. El primer paso es una lista completa de lo que corre en tu WordPress: versión del núcleo, tema activo, tema padre si usas uno hijo, todos los plugins (activos e inactivos) con su número de versión, y la versión de PHP.
El detalle que casi todo el mundo pasa por alto: los plugins desactivados también son código presente en el servidor. Un plugin desactivado con una vulnerabilidad conocida sigue siendo un fichero al que se puede llegar por URL. Si no lo usas, no lo desactives: bórralo.
Para sacar el listado sin instalar nada, ve a Plugins > Plugins instalados, selecciona todo el texto de la tabla y pégalo en un documento. En Werkzeuge > Website-Zustand > Informationen tienes la versión de PHP, la del servidor y la de la base de datos, todo junto y copiable con un botón.
Si mantienes varias webs, este inventario merece vivir en una hoja de cálculo y actualizarse cada trimestre. Es la base de todo lo demás.
Paso 2: contrasta contra vulnerabilidades conocidas
Aquí está el paso que más gente se salta y el que más problemas evita.
Existen bases de datos públicas que registran las vulnerabilidades publicadas de plugins y temas de WordPress. Las dos de referencia son WPScan y Patchstack. Ambas tienen buscador web gratuito: introduces el nombre del plugin y te dice si hay vulnerabilidades registradas y en qué versiones.
El procedimiento correcto es este:
- Coge tu inventario del paso 1.
- Pide a la IA que te ordene la lista por antigüedad de la última actualización, marcando los que lleven más de un año sin tocarse.
- Suchen Sie uno por uno en WPScan o Patchstack los que la IA haya marcado.
- Anota: nombre, versión que tienes, versión corregida, gravedad.
Fíjate en el orden. La IA acota el trabajo —te dice qué mirar primero— pero la comprobación la haces tú contra la fuente oficial. Preguntarle directamente a un modelo «¿tiene vulnerabilidades el plugin X versión 2.1?» es una mala idea: los datos de vulnerabilidades cambian cada semana y el modelo puede responder con confianza sobre algo que no sabe.
Si un plugin tiene una vulnerabilidad sin parche disponible, la decisión no es técnica sino de negocio: buscar alternativa, o asumir el riesgo documentándolo. En nuestra guía sobre cómo actualizar plugins de WordPress de forma segura explicamos cómo aplicar estas actualizaciones sin romper la web por el camino.
Paso 3: revisa usuarios y accesos
La vía de entrada más común no es una vulnerabilidad exótica: es una cuenta que no debería existir o una contraseña débil.
In Usuarios, revisa:
- Cuántos administradores hay. Deberían ser los mínimos imprescindibles. Cada administrador es una llave maestra.
- Cuentas de gente que ya no está: la agencia anterior, el becario del verano pasado, el desarrollador de aquel encargo puntual.
- Cuentas con nombre genérico como «admin», «wordpress» o «test».
- Fecha del último acceso, si tu plugin de seguridad la registra. Una cuenta de administrador que nadie usa desde hace ocho meses es un riesgo sin contrapartida.
Y sobre las contraseñas: no reutilices ninguna, y que sean largas. Puedes crear una en dos segundos con nuestro sicherer Passwort-Generator, que funciona en tu propio navegador sin enviar nada a ningún servidor.
Activa además la verificación en dos pasos para todas las cuentas de administrador. Es la medida que mejor relación esfuerzo-protección tiene de toda esta lista.
Paso 4: comprueba la integridad de los ficheros
WordPress publica las sumas de verificación de todos los ficheros de cada versión del núcleo. Eso permite detectar si alguno ha sido modificado.
Los plugins de seguridad serios incluyen esta comprobación. En Wordfence está en Scan, y compara tus ficheros del núcleo, temas y plugins del repositorio oficial contra los originales. Si aparece un fichero modificado que tú no has tocado, ahí tienes algo que investigar.
Dos avisos importantes sobre los resultados:
- Los falsos positivos existen. Un tema hijo, un snippet propio o una personalización legítima aparecerán como «modificado». Eso no es un ataque.
- Que no salga nada no significa que estés limpio. Un fichero malicioso nuevo en una carpeta de subidas no aparece como «modificado» porque no había original con el que compararlo.
Aquí la IA sí ayuda de verdad: pégale el contenido de un fichero sospechoso y pídele que te explique qué hace. Es especialmente buena detectando código ofuscado —esas líneas larguísimas llenas de base64_decode y eval que no tienen ninguna razón legítima para estar en un tema. Si ya tienes indicios de que la web está comprometida, nuestra guía de limpieza de un WordPress bajo ataque cubre el proceso completo de desinfección, que es un trabajo distinto de esta auditoría.
Paso 5: audita la configuración
Esta es la parte donde la IA rinde mejor, porque se trata de leer configuración y detectar desviaciones.
Revisa estos puntos:
- Edición de ficheros desde el escritorio. Si un atacante entra con una cuenta de administrador, el editor de temas le da ejecución de código directa. Se desactiva con
define('DISALLOW_FILE_EDIT', true);inwp-config.php. - Depuración en producción.
WP_DEBUGdebe estar afalseen una web en producción. Si está activo, los mensajes de error pueden revelar rutas del servidor. - Permisos de ficheros. Lo habitual es 644 para ficheros y 755 para carpetas. Nada debería estar en 777.
- XML-RPC. Si no usas la aplicación móvil de WordPress ni Jetpack, probablemente no lo necesitas, y es un objetivo habitual de ataques de fuerza bruta.
- Listado de directorios. Entra en
tudominio.com/wp-content/uploads/. Si ves un listado de carpetas en lugar de un error, tienes el listado de directorios activo y conviene desactivarlo. - Versión de PHP. Una versión sin soporte no recibe parches de seguridad. Tenemos una guía de cómo actualizar PHP en WordPress sin llevarte sustos.
Un prompt que funciona bien para esta fase, pegando debajo tu wp-config.php con las credenciales de base de datos y las claves de seguridad borradas:
«Eres un auditor de seguridad de WordPress. Te paso un wp-config.php con los datos sensibles ya eliminados. Revisa la configuración y dime: qué constantes de seguridad recomendadas faltan, qué ajustes son inadecuados para un entorno de producción, y qué encuentras que no sea estándar de una instalación normal. Ordena los hallazgos por riesgo, de mayor a menor, y para cada uno explica la consecuencia concreta si se explota. No inventes: si algo no puedes determinarlo con lo que te he dado, dilo.»
Esa última frase importa. Pedir explícitamente que reconozca lo que no sabe reduce mucho las respuestas inventadas.
Paso 6: revisa las cabeceras de seguridad
Las cabeceras HTTP son instrucciones que tu servidor manda al navegador del visitante. Bien puestas, cierran familias enteras de ataques.
Comprueba las tuyas en un analizador gratuito como securityheaders.com: introduces tu dominio y te da una nota con lo que falta. Las que más importan son Strict-Transport-Security, que obliga a usar HTTPS siempre; X-Content-Type-Options, que evita que el navegador adivine tipos de fichero; y Content-Security-Policy, la más potente y también la más fácil de configurar mal.
Sobre esta última, un consejo práctico: una CSP mal escrita rompe la web, y suele romper justo lo que da dinero (el formulario, la pasarela de pago, el chat). Si la implementas, hazlo primero en modo solo-informe durante unos días para ver qué bloquearía antes de aplicarla de verdad.
Paso 7: convierte los hallazgos en un plan
Una auditoría que termina en una lista de veinte cosas sueltas no sirve de nada, porque nadie sabe por dónde empezar. Aquí es donde la IA cierra el círculo.
Pásale todos tus hallazgos y pídele que los organice así:
«Te paso los hallazgos de una auditoría de seguridad de WordPress. Organízalos en una tabla con estas columnas: hallazgo, riesgo (alto/medio/bajo), esfuerzo de corrección (minutos/horas/días) y orden recomendado de ejecución. Prioriza por riesgo dividido entre esfuerzo, de modo que lo primero sea lo que más protege con menos trabajo. Añade una columna final indicando si el cambio puede romper la web y necesita hacerse en un entorno de pruebas.»
Esa última columna es la que te ahorra el disgusto. Hay correcciones que aplicas en caliente sin miedo, y otras —tocar permisos, cambiar la versión de PHP, meter una CSP— que se prueban antes en un entorno de pruebas.
Los límites: cuándo esto no basta
Todo lo anterior es una auditoría de configuración y superficie de ataque. Cubre la enorme mayoría de los casos reales, porque la enorme mayoría de los WordPress comprometidos lo están por un plugin desactualizado o una contraseña débil, no por un ataque sofisticado.
Hay situaciones en las que esto se queda corto y conviene que lo mire una persona:
- Ya hay indicios de compromiso: redirecciones extrañas, spam en los resultados de Google, avisos del navegador. Eso ya no es una auditoría, es una respuesta a incidente, y el orden de las tareas es completamente distinto.
- La web maneja pagos o datos personales sensibles. Ahí entran obligaciones legales que ninguna herramienta automática va a evaluar por ti.
- Hay desarrollo a medida. Un plugin propio o un tema hecho a mano tienen su propio código, y ese código nadie lo ha revisado nunca. Una auditoría de configuración no lo cubre.
- Es una web crítica para el negocio. Si un día de caída te cuesta más de lo que cuesta una revisión profesional, la cuenta sale sola.
Häufig gestellte Fragen
¿Cada cuánto debería auditar mi WordPress?
Una revisión completa como la de esta guía, dos veces al año. La comprobación de vulnerabilidades del paso 2, cada mes: es la que más rápido caduca, porque se publican vulnerabilidades nuevas cada semana. Y siempre después de un cambio grande, como añadir un plugin importante o cambiar de tema.
¿Puedo pasarle mi wp-config.php entero a una IA?
No sin limpiarlo antes. Ese fichero contiene el usuario y la contraseña de tu base de datos y las claves de seguridad de las sesiones. Borra esos valores, sustitúyelos por texto genérico y entonces sí puedes pedir la revisión. Lo mismo vale para cualquier fichero de registro que pueda contener direcciones IP o datos de usuarios.
¿Un plugin de seguridad sustituye a la auditoría?
No, hacen cosas distintas. El plugin es vigilancia continua: bloquea intentos de acceso, filtra tráfico y avisa de cambios. La auditoría es una revisión puntual de si tu configuración es correcta y tu software está al día. Un plugin de seguridad perfectamente configurado no te protege de un plugin con una vulnerabilidad conocida que llevas dos años sin actualizar. Si quieres exprimir el tuyo, tenemos una guía de ajustes poco conocidos de Wordfence.
¿Qué hago si encuentro algo grave?
Antes de tocar nada, copia de seguridad completa: ficheros y base de datos. Después aplica la corrección en un entorno de pruebas si el cambio es delicado, y en producción si es trivial (actualizar un plugin, borrar una cuenta). Si lo que has encontrado es un fichero malicioso, no te limites a borrarlo: casi nunca vienen solos, y hay que averiguar por dónde entró o volverá a aparecer.
Para terminar
La inteligencia artificial no hace la auditoría por ti, pero sí convierte una tarea de especialista en algo que puedes hacer tú con método. Te acota dónde mirar, te traduce lo técnico y te ordena el resultado en un plan ejecutable.
Lo que no delega es el criterio: qué riesgo asumes, qué compruebas contra la fuente oficial y qué cambios pruebas antes de aplicar. Esa parte sigue siendo tuya, y es justo la que marca la diferencia entre una auditoría de verdad y una lista de recomendaciones genéricas.
Si quieres seguir por aquí, en nuestra biblioteca de herramientas gratuitas tienes utilidades que funcionan enteras en tu navegador, sin subir nada a ningún servidor.
