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 Outils > Santé du site > Informations 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.
- Recherchez 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.
Dans 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 générateur de mots de passe sécurisés, 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 Analyse, 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);enwp-config.php. - Depuración en producción.
WP_DEBUGdoit être àfalsesur un site web en production. S'il est actif, les messages d'erreur peuvent révéler des chemins de serveur. - Permissions des fichiers. L'habituel est 644 pour les fichiers et 755 pour les dossiers. Rien ne devrait être en 777.
- XML-RPC. Si vous n'utilisez pas l'application mobile WordPress ni Jetpack, vous n'en avez probablement pas besoin, et c'est une cible habituelle des attaques par force brute.
- Affichage des répertoires. Entra en
tudominio.com/wp-content/uploads/. Si vous voyez une liste de dossiers au lieu d'une erreur, vous avez l'affichage des répertoires actif et il convient de le désactiver. - Version de PHP. Une version sans support ne reçoit pas de correctifs de sécurité. Nous avons un guide sur comment mettre à jour PHP dans WordPress sans avoir de mauvaises surprises.
Un prompt qui fonctionne bien pour cette phase, en collant en dessous votre wp-config.php avec les identifiants de base de données et les clés de sécurité supprimés:
«Tu es un auditeur de sécurité WordPress. Je te transmets un wp-config.php avec les données sensibles déjà supprimées. Examine la configuration et dis-moi : quelles constantes de sécurité recommandées manquent, quels réglages sont inappropriés pour un environnement de production, et ce que tu trouves qui n'est pas standard pour une installation normale. Classe les constats par risque, du plus élevé au moins élevé, et pour chacun explique la conséquence concrète s'il est exploité. N'invente pas : si tu ne peux pas déterminer quelque chose avec ce que je t'ai donné, dis-le.»
Cette dernière phrase est importante. Demander explicitement qu'il reconnaisse ce qu'il ne sait pas réduit considérablement les réponses inventées.
Étape 6 : révisez les en-têtes de sécurité
Les en-têtes HTTP sont des instructions que votre serveur envoie au navigateur du visiteur. Bien configurées, elles bloquent des familles entières d'attaques.
Vérifiez les vôtres dans un analyseur gratuit comme securityheaders.com: vous entrez votre domaine et il vous donne une note avec ce qui manque. Celles qui importent le plus sont Strict-Transport-Security, qui oblige à toujours utiliser HTTPS ; X-Content-Type-Options, qui empêche le navigateur de deviner les types de fichiers ; et Content-Security-Policy, la plus puissante et aussi la plus facile à mal configurer.
Concernant cette dernière, un conseil pratique : une CSP mal écrite casse le site web, et a tendance à casser précisément ce qui rapporte de l'argent (le formulaire, la passerelle de paiement, le chat). Si vous l'implémentez, faites-le d'abord en mode rapport uniquement pendant quelques jours pour voir ce qu'elle bloquerait avant de l'appliquer réellement.
Étape 7 : transforme les constats en un plan
Un audit qui se termine par une liste de vingt choses éparses ne sert à rien, car personne ne sait par où commencer. C'est là que l'IA boucle la boucle.
Transmets-lui tous tes constats et demande-lui de les organiser ainsi :
«Je te transmets les résultats d'un audit de sécurité WordPress. Organise-les dans un tableau avec ces colonnes : constat, risque (élevé/moyen/faible), effort de correction (minutes/heures/jours) et ordre d'exécution recommandé. Priorise par risque divisé par effort, de sorte que le premier soit ce qui protège le plus avec le moins de travail. Ajoute une colonne finale indiquant si le changement peut casser le site web et doit être effectué dans un environnement de test.»
Cette dernière colonne est celle qui vous épargne les ennuis. Il y a des corrections que vous appliquez à chaud sans crainte, et d'autres — toucher aux permissions, changer la version de PHP, insérer une CSP — qui sont testées au préalable dans un environnement de test.
Les limites : quand cela ne suffit pas
Tout ce qui précède est un audit de configuration et de surface d'attaque. Il couvre l'énorme majorité des cas réels, car l'énorme majorité des WordPress compromis le sont à cause d'un plugin obsolète ou d'un mot de passe faible, et non d'une attaque sophistiquée.
Il y a des situations où cela est insuffisant et il convient qu'une personne y jette un œil :
- Il y a déjà des signes de compromission: redirections étranges, spam dans les résultats Google, avertissements du navigateur. Ce n'est plus un audit, c'est une réponse à incident, et l'ordre des tâches est complètement différent.
- Le site web gère des paiements ou des données personnelles sensibles. Là entrent en jeu des obligations légales qu'aucun outil automatique n'évaluera pour vous.
- Il y a du développement sur mesure. Un plugin propriétaire ou un thème fait à la main ont leur propre code, et ce code n'a jamais été révisé par personne. Un audit de configuration ne le couvre pas.
- C'est un site web critique pour l'entreprise. Si un jour d'interruption vous coûte plus cher qu'une révision professionnelle, le calcul est vite fait.
Questions fréquentes
À quelle fréquence devrais-je auditer mon WordPress ?
Une révision complète comme celle de ce guide, deux fois par an. La vérification des vulnérabilités de l'étape 2, chaque mois : c'est celle qui expire le plus rapidement, car de nouvelles vulnérabilités sont publiées chaque semaine. Et toujours après un changement majeur, comme l'ajout d'un plugin important ou le changement de thème.
Puis-je transmettre mon wp-config.php entier à une IA ?
Non, pas sans le nettoyer d'abord. Ce fichier contient le nom d'utilisateur et le mot de passe de votre base de données ainsi que les clés de sécurité des sessions. Supprimez ces valeurs, remplacez-les par du texte générique et alors seulement vous pourrez demander la révision. Il en va de même pour tout fichier journal susceptible de contenir des adresses IP ou des données utilisateur.
Un plugin de sécurité remplace-t-il l'audit ?
Non, ils font des choses différentes. Le plugin est une surveillance continue : il bloque les tentatives d'accès, filtre le trafic et signale les changements. L'audit est une révision ponctuelle pour vérifier si votre configuration est correcte et si votre logiciel est à jour. Un plugin de sécurité parfaitement configuré ne vous protège pas d'un plugin avec une vulnérabilité connue que vous n'avez pas mis à jour depuis deux ans. Si vous voulez tirer le meilleur du vôtre, nous avons un guide de paramètres peu connus de Wordfence.
Que faire si je trouve quelque chose de grave ?
Avant de toucher à quoi que ce soit, sauvegarde complète : fichiers et base de données. Appliquez ensuite la correction dans un environnement de test si le changement est délicat, et en production s'il est trivial (mettre à jour un plugin, supprimer un compte). Si ce que vous avez trouvé est un fichier malveillant, ne vous contentez pas de le supprimer : ils ne viennent presque jamais seuls, et il faut découvrir par où il est entré ou il réapparaîtra.
Pour finir
L'intelligence artificielle ne fait pas l'audit pour vous, mais elle transforme une tâche de spécialiste en quelque chose que vous pouvez faire avec méthode. Elle délimite où regarder, traduit le jargon technique et organise le résultat en un plan exécutable.
Ce qu'elle ne délègue pas, c'est le jugement : quel risque vous assumez, ce que vous vérifiez par rapport à la source officielle et quels changements vous testez avant d'appliquer. Cette partie reste la vôtre, et c'est précisément ce qui fait la différence entre un véritable audit et une liste de recommandations génériques.
Si vous voulez continuer par ici, dans notre bibliothèque d'outils gratuits vous avez des utilitaires qui fonctionnent entièrement dans votre navigateur, sans rien télécharger sur aucun serveur.
