Un formulaire de contact, un espace client, un simple blog WordPress : chaque site web expose des portes d’entrée que des attaquants testent en permanence. Les failles de sécurité les plus courantes dans les sites web ne sont pas toujours spectaculaires. Elles tiennent souvent à un réglage oublié, un plugin pas mis à jour ou un contrôle d’accès mal configuré côté serveur.
Contrôle d’accès défaillant : la faille qui domine le classement OWASP
Vous avez déjà vu une URL du type monsite.fr/compte/utilisateur/142 ? Si rien n’empêche un visiteur de remplacer 142 par 143, il accède potentiellement au compte d’un autre utilisateur. Ce type de problème porte un nom technique : broken access control.
Concrètement, le serveur ne vérifie pas si la personne connectée a le droit de consulter la ressource demandée. Le code affiche la page sans poser de question. Selon le référentiel OWASP Top 10:2025, cette catégorie de faille reste en première position pour la quatrième édition consécutive.
Le problème ne se limite pas aux URL. Il touche aussi les interfaces d’administration accessibles sans restriction, les API qui renvoient des données à n’importe quel appelant, ou les fonctions de suppression et de modification ouvertes à des rôles non autorisés. Un contrôle d’accès se vérifie côté serveur, jamais côté navigateur.
Erreurs de configuration serveur et CMS WordPress
Une deuxième famille de failles ne provient pas du code de l’application, mais de son environnement. On parle d’erreurs de configuration de sécurité, et elles ont nettement progressé dans le classement OWASP ces dernières années.
Quelques exemples concrets pour comprendre le mécanisme :
- Un serveur web qui affiche la liste des fichiers d’un répertoire parce que le listing n’a pas été désactivé, exposant des sauvegardes ou des fichiers de configuration
- Un site WordPress livré avec le préfixe de table par défaut, le fichier
wp-config.phpaccessible en lecture, ou un compte admin conservant l’identifiant « admin » - Des en-têtes HTTP de sécurité absents (Content-Security-Policy, X-Frame-Options), ce qui facilite certaines attaques par injection de contenu
- Un mode debug laissé actif en production, affichant les messages d’erreur PHP avec les chemins complets du serveur
Ces failles ne demandent aucune compétence avancée pour être exploitées. Un simple scan automatisé les détecte en quelques secondes. La majorité des erreurs de configuration se corrigent sans toucher au code, uniquement par des réglages serveur ou des ajustements dans la gestion du CMS.
Injection SQL et XSS : deux failles web toujours actives
L’injection SQL existe depuis la fin des années 1990. Le principe reste le même : un champ de formulaire (recherche, login, commentaire) transmet des données au serveur, qui les insère directement dans une requête de base de données sans les filtrer.
Comment fonctionne une injection SQL
Imaginez un champ de recherche. Au lieu de taper un mot-clé, un attaquant saisit un fragment de code SQL. Si le serveur ne nettoie pas cette entrée, la requête est modifiée. Elle peut alors extraire la liste des utilisateurs, leurs mots de passe, ou supprimer des tables entières.
La parade est connue : utiliser des requêtes paramétrées (aussi appelées requêtes préparées). Le serveur traite alors la saisie comme une donnée brute, jamais comme une instruction. Les plugins WordPress mal codés restent une source fréquente d’injections SQL, car leurs auteurs n’utilisent pas toujours les fonctions de préparation fournies par le CMS.
Le cas du cross-site scripting (XSS)
Le XSS fonctionne différemment. L’attaquant injecte du code JavaScript dans une page qui sera affichée à d’autres visiteurs. Un commentaire piégé sur un blog, un champ de profil mal filtré : le script s’exécute dans le navigateur de la victime.
Les conséquences vont du vol de cookie de session (qui permet de se connecter au compte de l’utilisateur) à la redirection vers un site frauduleux. Chaque donnée affichée dans une page doit être échappée avant rendu, c’est-à-dire transformée pour que le navigateur l’interprète comme du texte et non comme du code.
Failles de la chaîne d’approvisionnement logicielle : plugins, dépendances et mises à jour
Le référentiel OWASP 2025 a créé une catégorie dédiée aux défaillances de la chaîne d’approvisionnement logicielle. Derrière ce terme se cache un problème très concret pour les sites web : les composants tiers que vous installez sans les auditer.
Sur un site WordPress, cela concerne directement les plugins et les thèmes. Chaque extension ajoute du code développé par un tiers, avec son propre niveau de rigueur en matière de cybersécurité. Un plugin abandonné par son auteur ne recevra plus de correctifs, même si une faille y est découverte.
Le risque ne s’arrête pas aux CMS. Les projets PHP qui utilisent des gestionnaires de dépendances comme Composer importent des bibliothèques hébergées sur des registres publics. Si l’un de ces paquets est compromis, ou si un attaquant publie un paquet au nom quasi identique (typosquatting), le code malveillant s’installe dans votre projet sans déclencher d’alerte.
La gestion de ce risque passe par des outils d’analyse de composition logicielle qui comparent vos dépendances à des bases de vulnérabilités connues. Sur WordPress, la règle de base consiste à limiter le nombre de plugins au strict nécessaire et à supprimer ceux qui ne sont plus maintenus.
Protéger un site web : les vérifications qui comptent
Plutôt qu’une liste de bonnes pratiques génériques, voici les points qui, dans la réalité, séparent un site vulnérable d’un site raisonnablement protégé :
- Appliquer les mises à jour de sécurité du CMS, des plugins et du serveur dans les jours qui suivent leur publication, pas au trimestre suivant
- Vérifier que chaque action sensible (modification de données, accès à un compte, appel API) contrôle les droits de l’utilisateur côté serveur
- Désactiver tout ce qui n’est pas utilisé : modules PHP inutiles, fonctions d’administration exposées, ports réseau ouverts
- Mettre en place une journalisation des accès et des erreurs, parce qu’une attaque non détectée peut durer des mois
La sécurité d’un site web n’est pas un état figé. Les systèmes évoluent, les attaques aussi. Un audit régulier des configurations et des dépendances reste le levier le plus efficace pour réduire la surface d’exposition, que le site tourne sur WordPress, un framework PHP ou une architecture sur mesure.
