Audit de sécurité WordPress sur-mesure.
Un audit de sécurité WordPress consiste à tester votre site tel qu'il existe réellement : le cœur, mais surtout les extensions, le thème sur mesure, les rôles et tout ce que les années ont empilé dessus. C'est là que un hacker peut s'infiltrer, et un plugin de sécurité ne le voit pas.
Le problème n'est presque jamais WordPress.
Le cœur de WordPress est relu par beaucoup de monde et corrigé vite. Ce n'est pas là que je trouve des failles, et ce n'est pas là que les attaquants en trouvent non plus.
Le risque vient de ce qu'on ajoute. Une extension gratuite écrite il y a six ans par un auteur qui a arrêté de la maintenir. Un thème sur mesure livré par une agence, jamais relu depuis, avec un formulaire de contact qui construit sa requête à la main. Une action AJAX enregistrée pour les utilisateurs connectés mais qui oublie de vérifier quelle capacité l'appelant possède. Un ancien plugin désactivé mais toujours présent sur le disque, et toujours accessible directement par son URL.
Ces failles n'existent que sur votre installation. Aucune base de signatures ne les contient, donc aucun scanner ne vous les signalera. Elles se trouvent en lisant et en manipulant, ce qui est exactement le travail que je fais.
Ce que je teste.
Un site WordPress a des points d'entrée qui lui sont propres. Voici ceux que je couvre systématiquement.
- Extensions installées : versions vulnérables connues, mais surtout failles propres à votre configuration et à vos combinaisons d'extensions.
- Thème sur mesure : requêtes construites à la main, sorties non échappées, fichiers PHP appelables directement.
- Rôles et capacités : ce qu'un abonné, un contributeur ou un auteur peut réellement atteindre, au-delà de ce que le menu affiche.
- Actions AJAX et hooks : absence de vérification de capacité ou de nonce sur les points d'entrée enregistrés par les extensions.
- API REST et XML-RPC : endpoints exposés par défaut ou par les extensions, énumération d'utilisateurs, écriture non contrôlée.
- Médiathèque et uploads : types de fichiers acceptés, exécution possible, écrasement de fichiers existants.
- Exposition de fichiers : sauvegardes accessibles, journaux de débogage, fichiers de configuration laissés sur le serveur, dépôts Git publiés par erreur.
- WooCommerce si présent : tunnel de commande, règles de remise, webhooks de paiement, accès aux données clients.
Comment se passe une mission.
Cadrage
On identifie le site, les rôles utilisés, la présence d'un thème sur mesure ou d'extensions développées spécifiquement pour vous, et ce qui est exclu. Contrat de test et NDA signés avant tout accès.
Inventaire
Recensement des extensions et de leurs versions, du thème, des points d'entrée exposés, et de tout ce qui traîne sur le serveur sans être référencé nulle part. Cette étape seule remonte régulièrement des surprises : un ancien site de recette accessible, une sauvegarde téléchargeable, une extension désactivée mais toujours atteignable.
Test des rôles
Je me connecte avec chaque rôle et je tente d'atteindre ce qui ne m'est pas destiné : actions d'administration, contenus d'autres auteurs, réglages du site, actions AJAX réservées. Les escalades de privilèges dans WordPress viennent presque toujours d'une capacité mal vérifiée dans une extension.
Analyse du sur-mesure
Le code écrit pour vous reçoit l'attention la plus soutenue, puisque c'est le seul que personne d'autre au monde n'a relu. Formulaires, requêtes, affichage de données saisies par les utilisateurs, traitement des fichiers.
Rapport, débrief, retest
Rapport priorisé par criticité réelle, avec une preuve de concept reproductible et une remédiation concrète pour chaque faille, formulée pour être applicable par votre agence ou votre développeur. Débrief, puis retest de chaque correctif, inclus.
Ce que ça donne en pratique.
Types de failles rencontrées sur des installations réelles. Les clients et les périmètres ne sont jamais divulgués.
Combien ça coûte.
Sur devis, selon les mêmes variables que partout ailleurs. Sur WordPress, trois éléments font l'essentiel de l'écart.
Le volume de code sur mesure, d'abord : un site monté avec des extensions du dépôt officiel et un thème du commerce demande beaucoup moins de temps qu'un site dont l'agence a écrit la moitié des fonctionnalités. Ensuite le nombre d'extensions, et surtout leur nature : celles qui ajoutent des formulaires, des espaces membres, des droits ou des paiements comptent bien plus que celles qui gèrent un cache. Enfin la présence de WooCommerce ou d'un espace client, qui ajoute une couche entière de logique métier à tester.
Un site vitrine de quelques pages se traite rapidement. Une boutique avec comptes clients, remises et intégrations demande un vrai chantier. Le premier échange sert à savoir dans quel cas vous êtes.
Questions fréquentes.
WordPress est-il un CMS peu sûr ?
Le cœur de WordPress est audité en permanence et corrigé vite. Le risque vient de l'écosystème : des extensions écrites par des auteurs très inégaux, des thèmes sur mesure jamais relus, et des sites qui accumulent des années de dépendances. En pratique, presque toutes les compromissions que je vois passent par un élément ajouté, pas par le cœur.
Un plugin de sécurité ne suffit-il pas ?
Un plugin de sécurité bloque les attaques connues et génériques, ce qui est utile. Il ne détecte pas qu'une extension expose une action AJAX sans vérification de capacité, ni qu'un formulaire sur mesure écrit par votre agence permet une injection. Ces failles sont propres à votre installation, donc absentes de toute base de signatures.
L'audit se fait-il sur le site en production ?
Oui dans la plupart des cas, sans interruption de service. Les tests destructifs sont exclus par défaut. Si vous disposez d'une copie de préproduction fidèle, on peut y travailler pour les tests les plus intrusifs, puis confirmer les points sensibles en production.
Faut-il me donner un accès administrateur ?
Un compte de chaque rôle utilisé sur le site est recommandé, y compris un compte administrateur si le périmètre inclut les escalades de privilèges. C'est ce qui permet de vérifier qu'un abonné ou un contributeur ne peut pas atteindre des capacités qui ne lui reviennent pas.
Testez-vous aussi WooCommerce ?
Oui. Une boutique WooCommerce ajoute un tunnel de commande, des règles de remise, des webhooks de paiement et des données clients, donc une surface de logique métier importante. C'est souvent la partie la plus intéressante à tester sur un site WordPress.
Les autres prestations.
Test d'intrusion web
Pour une application qui n'est pas sous WordPress, ou pour aller plus loin que le CMS : parcours utilisateur, rôles et logique métier.
DécouvrirAudit de sécurité d'API
Si votre WordPress sert de back-office à une application ou à un front découplé, l'API mérite son propre audit.
DécouvrirFaites auditer votre WordPress.
Dites-moi combien d'extensions tourne votre site, s'il a un thème sur mesure, et s'il y a un espace client ou une boutique. Je vous réponds avec un cadrage et un devis. Premier échange sans engagement, confidentialité totale.