Les failles de sécurité qui exposent votre site web
Retrouvez chaque mois sur notre blog : des astuces, des bonnes pratiques, des conseils et des retours d’expérience sur la mise en place de votre stratégie digitale.
En 2025, plus de 11 300 nouvelles vulnérabilités ont été recensées dans l’écosystème WordPress, un record, en hausse de 42 % par rapport à 2024. Le délai médian entre la publication d’une faille et sa première exploitation ? 5 heures.
Ces chiffres disent qu’un site web n’est jamais « trop petit » pour intéresser un attaquant, et que la sécurité ne peut plus être une réflexion après-coup.
Cet article détaille les failles les plus courantes, avec pour chacune les actions concrètes à mettre en place : sur WordPress puisqu’il concerne plus de 43 % des sites web dans le monde, et en générique pour le reste.
1. L’injection SQL
Ce qu’il faut faire :
- Ne jamais construire une requête SQL par concaténation de chaînes de caractères : utiliser systématiquement des requêtes préparées avec paramètres liés (prepared statements).
- Sur WordPress, utiliser $wpdb->prepare() pour toute requête personnalisée dans un thème ou un plugin : jamais d’injection directe de variables $_GET/$_POST dans une requête SQL.
- Restreindre les droits du compte de base de données utilisé par le site au strict nécessaire (pas de DROP, pas de GRANT si l’application n’en a pas besoin).
- Installer un pare-feu applicatif (WAF) : Wordfence, Sucuri, ou le WAF fourni par l’hébergeur/CDN (Cloudflare), qui filtre les patterns d’injection connus avant qu’ils n’atteignent l’application.
- Faire auditer le code des plugins maison ou sur mesure et ne pas se fier uniquement à la réputation d’un plugin du marketplace.
2. Le Cross-Site Scripting (XSS)
Ce qu’il faut faire :
- Échapper systématiquement toute donnée affichée qui provient d’une entrée utilisateur : sur WordPress, utiliser les fonctions dédiées (esc_html(), esc_attr(), esc_url(), esc_js()) selon le contexte d’affichage.
- Mettre en place une Content Security Policy (CSP) au niveau serveur ou via un plugin, pour limiter les sources de scripts autorisées à s’exécuter sur les pages.
- Activer l’attribut HttpOnly sur les cookies de session, pour empêcher un script injecté d’y accéder via JavaScript.
- Modérer les commentaires et désactiver l’insertion de HTML brut dans les champs publics si elle n’est pas indispensable.
- Mettre à jour sans délai tout plugin ou thème signalé pour une faille XSS : c’est la vulnérabilité la plus corrigée par patch, mais aussi la plus souvent ignorée faute de suivi.
3. Le Broken Access Control (contrôle d’accès défaillant)
Ce qu’il faut faire :
- Vérifier l’autorisation côté serveur à chaque requête, jamais seulement côté interface (masquer un bouton ne bloque pas un attaquant qui appelle l’endpoint directement).
- Sur WordPress, auditer les rôles et capacités (capabilities) attribués à chaque type de compte ; ne jamais donner un rôle « Administrateur » par défaut à un prestataire ou un contributeur externe.
- Vérifier les permissions des routes de l’API REST (/wp-json/) exposées par les plugins installés : beaucoup exposent des données par défaut sans authentification requise. Un scan avec un outil comme wpscan permet de les lister.
- Ne jamais se fier à un identifiant séquentiel ou devinable dans une URL (?user_id=42) sans vérifier que l’utilisateur courant a bien le droit d’accéder à cette ressource précise.
-
4. Les failles d’authentification et le brute force
Ce qu’il faut faire :
- Activer l’authentification à deux facteurs (2FA) sur tous les comptes ayant un accès d’administration : plugins comme Wordfence, WP 2FA, ou Google Authenticator pour WP.
- Limiter le nombre de tentatives de connexion (plugin de limitation, ou configuration du WAF) pour bloquer automatiquement une IP après quelques échecs.
- Changer l’URL par défaut de la page de connexion (/wp-login.php → une URL personnalisée), via un plugin comme WPS Hide Login, pour sortir des radars des bots génériques.
- Imposer des mots de passe robustes et uniques (gestionnaire de mots de passe recommandé pour les équipes), et interdire l’identifiant « admin » comme nom de connexion.
-
5. Les plugins et thèmes obsolètes ou vulnérables
Ce qu’il faut faire :
- Activer les mises à jour automatiques pour le cœur, les thèmes et les plugins dès que c’est possible, et à défaut vérifier et appliquer les mises à jour au moins une fois par semaine.
- Désinstaller (pas seulement désactiver) tout plugin ou thème non utilisé : un plugin désactivé reste un code présent sur le serveur et potentiellement exploitable.
- Avant d’installer un plugin, vérifier sa date de dernière mise à jour, le nombre d’installations actives et les avis récents : éviter tout plugin non mis à jour depuis plus de 12-18 mois.
- Utiliser un outil de scan de vulnérabilités (Patchstack, Wordfence, WPScan) qui alerte dès qu’une faille connue est identifiée sur un plugin installé, avant même la mise à disposition d’un correctif.
- Tester les mises à jour sur un environnement de staging avant de les appliquer en production, pour éviter qu’une mise à jour de sécurité ne casse le site et ne pousse à la repousser.
6. XML-RPC et les endpoints hérités
Ce qu’il faut faire :
- Désactiver XML-RPC si le site n’utilise pas d’application mobile de publication ni Jetpack (qui en dépend parfois), via un plugin comme Disable XML-RPC, ou en bloquant l’accès au fichier directement dans la configuration du serveur web (.htaccess ou bloc Nginx).
- Si XML-RPC doit rester actif pour un usage spécifique, restreindre son accès par IP ou via une règle de WAF ciblant spécifiquement les méthodes pingback et system.multicall.
- Auditer régulièrement les logs serveur pour repérer un pic de requêtes vers xmlrpc.php, souvent révélateur d’une tentative de brute force en cours.
7. Les téléversements de fichiers non sécurisés
Ce qu’il faut faire :
- Valider le type de fichier côté serveur par son contenu réel (signature binaire), pas uniquement par son extension ou son en-tête MIME déclaré, facilement falsifiables.
- Interdire l’exécution de scripts dans les dossiers de téléversement (wp-content/uploads sur WordPress) via une règle serveur bloquant l’exécution de PHP dans ce répertoire.
- Limiter la taille et le nombre de types de fichiers acceptés au strict nécessaire pour chaque formulaire (pas de .php, .exe, .sh sur un formulaire de candidature, par exemple).
-
8. Les erreurs de configuration serveur
Ce qu’il faut faire :
- Fixer les permissions de fichiers WordPress aux valeurs recommandées : 644 pour les fichiers, 755 pour les dossiers, et surtout ne jamais laisser wp-config.php en 666 ou 777.
- Désactiver l’affichage des erreurs PHP détaillées en production (display_errors = Off), pour ne pas exposer les chemins serveur ou la version des logiciels utilisés dans les messages d’erreur.
- Restreindre l’accès à /wp-admin par IP si l’équipe travaille depuis des adresses fixes, ou via une authentification supplémentaire au niveau du serveur (HTTP Basic Auth en plus du login WordPress).
- Désactiver l’édition de fichiers depuis l’interface WordPress (define(‘DISALLOW_FILE_EDIT’, true); dans wp-config.php), pour qu’un compte compromis ne puisse pas modifier le code du thème directement.
- Forcer HTTPS sur l’intégralité du site (redirection 301 systématique, en-tête HSTS), et vérifier le renouvellement automatique du certificat.
9. Les attaques DDoS
Ce qu’il faut faire :
- Passer le site derrière un CDN avec protection anti-DDoS intégrée (Cloudflare, Sucuri, ou l’offre équivalente de l’hébergeur) : c’est la mesure la plus efficace et la plus accessible, y compris pour un petit budget.
- Mettre en cache les pages statiques autant que possible (plugin de cache sur WordPress) pour réduire la charge serveur générée par un pic de trafic, légitime ou malveillant.
- Configurer des limites de taux (rate limiting) sur les endpoints sensibles (recherche, connexion, formulaires) qui sont les cibles privilégiées des attaques applicatives de type DDoS.
- Prévoir avec l’hébergeur un plan de montée en charge ou une bascule d’urgence en cas d’attaque prolongée.
10. Le facteur humain et l’ingénierie sociale
Ce qu’il faut faire :
- Ne jamais transmettre d’identifiants par email ou messagerie instantanée non chiffrée ; utiliser un gestionnaire de mots de passe partagé avec accès révocable.
- Former les équipes ayant accès au back-office à reconnaître les tentatives de phishing, en particulier les faux emails « mise à jour de sécurité WordPress » qui redirigent vers de fausses pages de connexion.
- Mettre en place une procédure claire de révocation des accès dès qu’un collaborateur ou prestataire quitte le projet : un compte oublié est une porte ouverte indéfiniment.
- Journaliser les connexions et actions d’administration (plugin d’audit log) pour pouvoir identifier rapidement l’origine d’un accès suspect.
Les priorités si vous ne devez retenir que trois actions
Si le temps ou le budget manque pour tout mettre en œuvre d’un coup, trois actions couvrent une large part du risque réel :
- activer les mises à jour automatiques (plugins, thèmes, cœur),
- activer la double authentification sur les comptes administrateurs,
- mettre en place des sauvegardes automatiques régulières et testées (une sauvegarde qu’on n’a jamais restaurée n’est pas une sauvegarde fiable)
FAQ
Un petit site vitrine risque-t-il vraiment d’être attaqué ?
Oui. La grande majorité des attaques sont automatisées et ne ciblent pas un site en particulier : des bots scannent en continu le web à la recherche de failles connues, quelle que soit la notoriété ou la taille du site.
WordPress est-il un CMS dangereux en soi ?
Non. Le cœur de WordPress est solide et ne représentait que 6 vulnérabilités mineures en 2025. Le risque vient à plus de 90 % des plugins et thèmes tiers, souvent développés par des équipes aux ressources limitées.
Faut-il installer un plugin de sécurité sur WordPress ?
Cela aide (pare-feu applicatif, blocage de brute force, scan de malware), mais ce n’est pas suffisant seul. Un plugin de sécurité ne remplace pas des mises à jour régulières et une hygiène de base sur les accès.
Combien de temps après la découverte d’une faille un site est-il attaqué ?
Le délai médian observé en 2025 est de 5 heures entre la divulgation publique d’une vulnérabilité et sa première exploitation. C’est ce qui rend les mises à jour automatiques indispensables.
Le HTTPS suffit-il à sécuriser un site ?
Non. Le HTTPS chiffre les échanges entre navigateur et serveur, mais ne protège en rien contre une injection SQL, un plugin vulnérable ou un mot de passe faible. C’est une brique parmi d’autres.
Que faire en priorité si on découvre que son site a été compromis ?
Isoler le site (mode maintenance ou coupure d’accès), changer immédiatement tous les mots de passe (admin, base de données, FTP/SFTP, hébergeur), restaurer une sauvegarde antérieure à la compromission si elle est saine, puis identifier la faille exploitée avant de remettre le site en ligne — sans quoi l’attaque se reproduira.
Sources : OWASP Top 10:2025 (owasp.org), Patchstack 2025 Mid-Year Vulnerability Report, Hide My WP Ghost — WordPress Security Statistics 2025-2026, Colorlib — WordPress Hacking Statistics 2026, Cloudflare DDoS Threat Report 2025, Verizon DBIR 2025.
Vous souhaitez maintenir votre site web ?
A découvrir sur le même thème !
