SecuChecker scanner de sécurité WordPress

Ce que SecuChecker scanne sur un site WordPress

Le scanner de sécurité WordPress SecuChecker titille les failles derrière la plupart des vraies intrusions, et voilà le côté un peu déprimant. La plupart des intrusions WordPress en 2026 remontent toujours aux mêmes failles ennuyeuses. Pas de Content Security Policy. Un header HSTS que personne n'a pris la peine d'envoyer. Un xmlrpc.php par défaut posé là, qui invite quasiment au brute-forcing d'identifiants. Un readme.html qui annonce gaiement votre version WordPress exacte à quiconque demande. Un listing wp-includes grand ouvert, le code du cœur et des plugins exposé. Ou ce REST endpoint à /wp-json/wp/v2/users qui distribue les logins des auteurs. SecuChecker tape sur tout ça en une seule passe et vous rend un score, du coup vous passez votre temps sur les correctifs qui réduisent vraiment la surface d'attaque plutôt que sur ceux qui donnent juste l'impression d'avancer.

En full depth, on touche dix-huit indicateurs. En mode quick, douze. La couche HTTP lit vos response headers et décortique HSTS, CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, plus ce que le serveur raconte sur lui-même et la façon dont il met en cache. La couche TLS vérifie si le certificat est valide, combien de jours restent avant l'expiration, et quels subject alternative names il couvre. La couche WordPress ? Elle examine la balise meta generator, le fichier readme, les directory listings, le REST users endpoint, le XML-RPC endpoint. Chaque check revient en pass, warn ou fail, avec la ligne exacte qui l'a déclenché, une sévérité (high, medium, low, info) et une ligne sur comment le corriger. Et encore une fois, rien de tout ça n'est intrusif. Pas de logins, pas de fuzzing, aucune tentative d'exploit. Juste des lectures publiques que n'importe quel visiteur de passage pourrait faire à la main.

Comment fonctionne le scanner de sécurité WordPress

1. Valider l'URL et identifier le nom d'hôte pour que TLS ait quelque chose à sonder.
2. Récupérer la page d'accueil via le serveur PeopleAreGeek, puis lire chaque response header qui revient.
3. Parser les security headers et noter chacun par rapport aux recommandations OWASP secure-headers pour 2026.
4. Sonder le TLS endpoint sur le port 443. On lit les métadonnées du certificat (issuer, validité, SAN) et on calcule les jours restants.
5. Sonder les chemins spécifiques à WordPress : /readme.html, /wp-login.php, /xmlrpc.php, /wp-includes/, /wp-content/uploads/, /?author=1, /wp-json/wp/v2/users. On capture le statut HTTP, la longueur, les headers clés.
6. Lire le HTML d'accueil à la recherche de la balise meta generator (qui balance en général votre version WordPress exacte) et des empreintes de plugins visibles à l'œil nu.
7. Noter et classer les findings par sévérité, puis tout ramener à un seul chiffre de posture de 0 à 100.

Cas d'usage courants pour SecuChecker

• Durcissement avant lancement. Lancez-le juste avant qu'un nouveau site passe en ligne. Il attrape les headers manquants et les fichiers par défaut que vous avez oublié de supprimer.
• Revue de sécurité mensuelle. Re-scannez après une mise à jour du cœur, un nouveau plugin, un changement d'hébergeur. La dérive de config provoque tranquillement à peu près la moitié des régressions que j'ai eu à traquer.
• Due diligence prestataire. Vous jaugez un freelance ou une agence ? Scannez les sites de leur portfolio et voyez si le discours sécu du pitch tient vraiment la route.
• Preuve de conformité. Beaucoup de frameworks plus légers (sécurité RGPD, une baseline ISO) veulent juste la preuve que vous avez vérifié. Le rapport téléchargeable couvre la part WordPress de tout ça.
• Tri d'incident. Après quelque chose qui sent mauvais, le scan vous dit si les portes faciles sont encore ouvertes. Les fermer, c'est en général la première étape du confinement.
• Lead magnet pour agences. Les freelances et les petites structures s'appuient sur le scan public comme accroche, une façon de lancer la conversation avant de proposer un vrai audit ou de l'hébergement managé.

Limites et notes de scan éthique

SecuChecker est un scanner en boîte noire, et un scanner poli. Il ne se connecte jamais. Il ne POSTera pas de formulaire, n'ira pas chasser l'injection SQL ou l'exécution de code à distance, ne fera rien qu'une personne saine d'esprit lirait comme une attaque. Il lit des endpoints publics et aligne les réponses sur une checklist de signaux de posture WordPress connus. Donc un rapport propre, c'est un bon début, oui, mais ce n'est pas la même chose qu'un vrai audit. Du code de plugin buggé, des mots de passe faibles, une escalade de rôles, un malware déjà actif sur la machine : tout ça se situe en dehors de ce qu'un scanner comme celui-ci peut voir. Vous voulez aller plus loin, avec une revue de plugins authentifiée et des findings au niveau du code ? Il existe un audit WordPress complet avec rapport PDF pour 49 euros (la carte d'upsell dans l'onglet Résumé donne les détails).

Une règle, et prenez-la au sérieux s'il vous plaît : ne scannez que des sites que vous possédez, ou pour lesquels vous avez une autorisation claire. Lancez des probes automatiques sur la machine de quelqu'un d'autre et certains hébergeurs le prendront comme un acte hostile, et on les comprend. SecuChecker se limite tout seul par session pour rester bien en dessous de n'importe quelle alarme raisonnable, mais le volet éthique, c'est à vous de le gérer, pas à l'outil. Et bon à savoir : chaque probe sort du serveur PeopleAreGeek, donc c'est cette IP que les gros CDN verront et loggueront.

Questions fréquentes

Que signifie le score de posture ?

C'est un total pondéré sur 100, chaque contrôle valant entre 5 et 15 points. Atteignez 85 ou plus et vous avez une baseline durcie. Atterrissez entre 60 et 85 et il vous manque quelques contrôles, même si rien n'est exposé de façon critique. Tombez sous 60 et il y a de vraies failles à haute sévérité, le genre qu'un attaquant opportuniste repère depuis l'extérieur sans trop forcer.

Le scan est-il sûr à lancer sur un site en production ?

Oui, c'est sans souci. Les probes sont des requêtes HEAD ou GET sur des URLs publiques, envoyées à un rythme tranquille. Rien n'est POSTé, aucun formulaire soumis, pas de brute force, pas de fuzzing. La plupart des WAF ne bronchent même pas, parce que le trafic ressemble juste à un crawl de moteur de recherche qui passe par là.

Pourquoi le scan signale-t-il ma version WordPress exposée ?

Une version affichée rend service à l'attaquant : elle réduit la liste des CVE à exactement ce qui pourrait marcher contre vous. Le correctif est minime. Retirez la balise meta generator avec un plugin ou un petit ajustement de thème, puis supprimez ou verrouillez le readme.html posé à la racine de votre document root.

Devrais-je désactiver xmlrpc.php ?

Si vous ne vous appuyez pas sur l'app Jetpack, les apps mobiles WordPress ou la publication à distance, alors oui, coupez-le. xmlrpc.php est l'ancien login endpoint que les gens détournent depuis des années, à la fois pour le brute-forcing et pour l'amplification de pingback. Bloquez-le au niveau du serveur web, ou laissez un plugin de sécurité s'en charger.

Un scan propre veut-il dire que mon site est sécurisé ?

Non, et je me méfierais de quiconque prétend le contraire. Un scan propre veut juste dire que les failles faciles sont fermées. Les bugs de plugins, les mots de passe faibles, quelqu'un qui se fait phisher, une dépendance empoisonnée en amont : rien de tout ça n'apparaît ici. Si vous voulez une vraie assurance, un audit authentifié est l'étape suivante honnête.