seolounge
Une faille de sécurité sur un site web est une faiblesse qui peut permettre à quelqu’un d’accéder à des données, de modifier une page ou d’agir avec les droits d’un autre utilisateur. Elle peut se cacher dans le code, une extension, les réglages du serveur ou la gestion des comptes.
Le plus utile est de comprendre ce qui ouvre la porte, puis ce qui la ferme réellement. Un formulaire de connexion, un commentaire ou un simple envoi de photo suffisent pour illustrer les principales vulnérabilités. Nous allons les reprendre avec des exemples et des corrections, avant de voir comment vérifier votre propre site.
Les extraits de code montrent un principe précis. Ils supposent que le reste de l’application, notamment la connexion à la base de données et l’authentification, est déjà correctement géré.
Comprendre la différence entre une faille et un piratage
Imaginons un espace client qui permet de télécharger une facture. Le visiteur doit être connecté, mais le serveur oublie de vérifier à qui appartient le document. Il existe une faille, même si personne ne l’a encore exploitée.
Une tentative apparaît lorsqu’une personne essaie d’accéder à une facture qui ne lui appartient pas. Si le serveur la lui transmet, des données ont été exposées. Ces trois situations demandent des réponses différentes.
Cette distinction aide aussi à lire les alertes. Des requêtes suspectes dans les journaux peuvent montrer que des robots testent le site. Elles ne prouvent pas qu’ils ont réussi. À l’inverse, une page qui semble normale peut cacher une fuite de données ou un compte administrateur ajouté discrètement.
La conséquence dépend des fonctions exposées et des permissions obtenues. Certaines failles touchent seulement un affichage. D’autres permettent de modifier des commandes, de récupérer des informations confidentielles ou d’exécuter du code sur le serveur.
Les principales failles et les protections correspondantes
Les noms se ressemblent parfois, mais les corrections ne sont pas interchangeables. Échapper un texte HTML ne protège pas une requête SQL. Un mot de passe solide ne remplace pas une vérification des permissions.
| Famille | Ce qui peut être détourné | Protection à privilégier |
|---|---|---|
| Injection SQL | Une requête vers la base de données | Requêtes préparées |
| XSS | Le contenu interprété par le navigateur | Échappement adapté au contexte |
| Contrôle d’accès | Les documents et fonctions d’un autre compte | Vérification des droits côté serveur |
| Authentification et CSRF | Une connexion ou une action sensible | MFA, sessions protégées et jetons CSRF |
| Upload et inclusion | Les fichiers reçus ou ouverts par le serveur | Validation réelle et ressources autorisées |
| XXE et SSRF | Les ressources consultées par l’application | Analyseurs durcis et destinations contrôlées |
| Configuration et composants | Les secrets, services et versions exposés | Réglages restrictifs et correctifs maintenus |
L’injection SQL modifie ce que vous demandez à la base
Prenons une boutique qui recherche des produits à partir d’un nom saisi dans un formulaire. Le problème apparaît lorsque le développeur colle directement cette saisie dans une instruction SQL. Une valeur prévue pour la recherche peut alors changer le sens de la requête.
Selon le contexte, cela peut exposer des données, modifier des enregistrements ou contourner un contrôle. Le risque ne se limite pas au formulaire visible. Les paramètres d’URL et les données reçues par une API peuvent aussi finir dans une requête.
Séparer les instructions des valeurs
Une requête préparée définit l’instruction avant de lui transmettre les valeurs. Voici le principe avec PHP et PDO.
$sql = 'SELECT id, nom FROM produits WHERE nom = :nom';
$requete = $pdo->prepare($sql);
$requete->execute(['nom' => $nomRecherche]);
$produits = $requete->fetchAll(PDO::FETCH_ASSOC);
Le nom recherché reste une valeur, même s’il contient une apostrophe. $pdo représente ici une connexion déjà configurée. La vérification du formulaire reste à prévoir autour de cet extrait.
Supprimer les apostrophes ou appliquer htmlspecialchars() n’offre pas cette protection. Les noms de colonnes et les options de tri demandent aussi un traitement particulier, avec un choix dans une liste autorisée. L’OWASP détaille ces protections contre les injections SQL.
Après correction, vérifiez que les recherches ordinaires fonctionnent toujours, y compris avec des apostrophes. Contrôlez également les autres requêtes construites de la même manière.
Comprendre les injections SQL en vidéo
Grafikart montre le rôle des requêtes préparées dans une démonstration en français.
Voir la vidéo sur YouTube · Grafikart · Français
La faille XSS fait interpréter un contenu comme du code
Un visiteur dépose un commentaire. Vous souhaitez afficher son texte, mais le navigateur reçoit un contenu qu’il interprète comme du code. C’est le principe d’une faille XSS, pour Cross-site scripting.
Le script peut modifier la page ou effectuer certaines actions avec la session du visiteur. L’impact dépend notamment du compte touché. Une injection qui s’affiche dans une interface d’administration peut avoir davantage de conséquences qu’un message visible dans une page publique.
Afficher du texte sans l’exécuter
Pour du texte inséré dans le corps d’une page HTML en PHP, l’échappement peut prendre cette forme.
echo htmlspecialchars(
$commentaire,
ENT_QUOTES | ENT_SUBSTITUTE,
'UTF-8'
);
Cet exemple concerne le texte HTML. Une URL, un attribut ou une valeur placée dans du JavaScript nécessite une protection adaptée à cet autre contexte. Dans le navigateur, textContent convient pour insérer du texte simple. Si vous acceptez du HTML enrichi, employez un outil d’assainissement prévu pour cela.
La politique CSP ajoute une protection, mais ne dispense pas de corriger les sorties. De même, un cookie HttpOnly n’empêche pas toutes les actions d’un script injecté. Le guide XSS de l’OWASP précise ces limites.
Pour vérifier la correction, contrôlez les endroits où le contenu réapparaît, notamment les aperçus, les résultats de recherche et l’administration. Une saisie peut être correctement affichée à un endroit et mal traitée ailleurs.
Comprendre les failles XSS en vidéo
Grafikart explique en français comment un contenu est interprété par le navigateur.
Voir la vidéo sur YouTube · Grafikart · Français
Un contrôle d’accès oublié expose les données des autres
Reprenons nos factures. Thomas se connecte à son compte et ouvre son document. Le serveur doit vérifier son identité, mais aussi son droit d’accès à cette facture précise.
Une faille IDOR apparaît lorsqu’un identifiant de ressource peut être utilisé sans contrôle d’autorisation suffisant. Masquer un bouton ne règle rien. Remplacer les numéros par des identifiants difficiles à deviner ne remplace pas non plus les permissions.
Vérifier le propriétaire à chaque demande
Une recherche peut être limitée aux factures du client connecté, avec des paramètres liés dans une requête préparée.
SELECT id, montant
FROM factures
WHERE id = :facture
AND client_id = :client_connecte
La valeur client_connecte vient de la session authentifiée sur le serveur. Elle ne doit pas provenir d’un champ que le visiteur peut modifier. Les comptes administrateurs et les documents partagés nécessitent leurs propres règles.
Sur votre environnement de test, créez deux clients et deux factures fictives. Chacun doit pouvoir consulter ses documents et recevoir un refus pour ceux de l’autre. Faites aussi le contrôle sur les modifications, les exports et les téléchargements directs. C’est le type de vérification recommandé par l’OWASP pour prévenir les IDOR.
Les attaques contre les mots de passe et les sessions
La force brute consiste à essayer des combinaisons pour trouver un secret. Dans la pratique, les tentatives de connexion utilisent aussi des mots de passe courants ou des identifiants récupérés lors d’une fuite sur un autre service.
Un mot de passe long et unique évite qu’un compte soit ouvert avec une combinaison réutilisée ailleurs. Ajoutez une authentification multifacteur quand elle est disponible. Le second facteur protège notamment lorsque le mot de passe seul a été volé.
Du côté de l’application, limitez les tentatives avec des mesures adaptées, surveillez les échecs inhabituels et protégez la récupération de compte. Un formulaire « mot de passe oublié » trop permissif peut ruiner les efforts consacrés à la connexion principale.
Les mots de passe doivent être stockés avec une fonction de hachage spécialisée et vérifiés avec l’API correspondante. MD5 et un simple SHA-256 maison ne conviennent pas. L’OWASP explique les règles de stockage des mots de passe.
Pour WordPress, mon guide sur la protection contre les attaques par force brute permet d’approfondir ce point. Pensez aussi aux comptes d’hébergement et de messagerie, qui peuvent donner un autre accès au site.
Comprendre le stockage des mots de passe
Ce complément de Grafikart, en français, porte sur le hachage des mots de passe. Les protections de connexion sont détaillées ci-dessus.
Voir la vidéo sur YouTube · Grafikart · Français
Une faille CSRF fait agir un utilisateur à son insu
Imaginons un administrateur connecté à son site. Une page extérieure provoque une demande de modification. Son navigateur joint automatiquement les cookies de session, mais l’application ne vérifie pas que la demande vient du formulaire attendu.
Une protection CSRF sert à contrôler cette demande. Les frameworks proposent généralement un mécanisme de jeton à intégrer au formulaire puis à vérifier côté serveur. Les opérations qui changent des données ne doivent pas se déclencher par une simple consultation d’URL.
La vérification du jeton s’ajoute aux droits de l’utilisateur. Dans WordPress, un nonce valide n’accorde aucune permission à lui seul. Il faut également vérifier la capacité nécessaire, par exemple avec current_user_can(). La documentation WordPress sur les nonces insiste sur cette différence.
Les réglages SameSite des cookies apportent une protection supplémentaire selon l’architecture. Ils ne remplacent pas systématiquement les contrôles CSRF. Après correction, testez qu’une demande privée de jeton est refusée et que le formulaire normal fonctionne encore.
Comprendre les demandes CSRF en vidéo
Grafikart illustre les attaques CSRF et leurs protections dans cette vidéo en français.
Voir la vidéo sur YouTube · Grafikart · Français
La faille upload commence avec un fichier accepté trop vite
Votre formulaire attend une photo de profil. Un fichier arrive avec un nom qui se termine par .jpg. Cela ne prouve pas qu’il s’agit d’une image valide. Le type annoncé par le navigateur peut lui aussi être falsifié.
La vérification doit se faire côté serveur. Limitez les formats réellement utiles, contrôlez le type du contenu et imposez une taille maximale. Pour une image, utilisez une bibliothèque maintenue capable de la décoder, avec des limites de dimensions et de ressources. Un contrôle MIME seul ne remplace pas cette validation.
Sécuriser aussi le stockage
Générez un nom aléatoire et choisissez vous-même le chemin de destination. Stockez les fichiers hors de la zone publique quand le fonctionnement le permet, puis servez-les après vérification des droits. Dans tous les cas, empêchez leur exécution comme scripts.
Un document client confidentiel ne doit pas devenir public simplement parce que son nom est difficile à deviner. Pour les documents complexes, une analyse antivirus ou une reconstruction du fichier peut compléter la validation. Ces mesures se choisissent selon les formats acceptés et les risques.
L’OWASP recommande plusieurs contrôles complémentaires pour les fichiers envoyés. Testez ensuite un fichier valide, un format refusé et un fichier trop volumineux. Vérifiez aussi les permissions de téléchargement.
Comprendre la protection des fichiers envoyés
Grafikart présente en français les précautions à prendre lorsqu’une application reçoit un fichier.
Voir la vidéo sur YouTube · Grafikart · Français
Les inclusions de fichiers LFI et RFI
Une application peut choisir le fichier à afficher à partir d’un paramètre. Si ce paramètre devient librement un chemin, le serveur risque d’ouvrir un fichier qui n’était pas prévu.
La LFI concerne l’inclusion de fichiers locaux. La RFI implique une ressource distante, lorsque le mécanisme utilisé et sa configuration le permettent. La lecture de fichiers et l’exécution de code dépendent du contexte, elles ne sont pas automatiques.
Pour une petite navigation PHP, mieux vaut faire correspondre les choix autorisés à des fichiers fixes.
$pages = [
'accueil' => __DIR__ . '/pages/accueil.php',
'contact' => __DIR__ . '/pages/contact.php',
];
$page = $_GET['page'] ?? 'accueil';
if (!is_string($page) || !isset($pages[$page])) {
http_response_code(404);
exit;
}
require $pages[$page];
L’utilisateur choisit ici un nom connu. Il ne fournit jamais le chemin réellement ouvert. Les valeurs inattendues sont refusées. Retirer seulement quelques caractères du paramètre n’offre pas la même maîtrise des ressources accessibles. Le guide OWASP sur la traversée de répertoires décrit les risques liés aux chemins manipulables.
Les failles XXE et SSRF détournent les ressources consultées
La vulnérabilité XXE concerne certains traitements XML. Un analyseur mal configuré peut résoudre une entité externe présente dans un document non fiable et consulter une ressource locale ou distante.
La correction consiste à désactiver les fonctions XML inutiles. Désactivez les DTD lorsque l’application n’en a pas besoin. Si elles sont indispensables, bloquez tout de même les entités externes et le chargement de DTD externes, avec les options prévues par votre analyseur.
Les options exactes dépendent de la bibliothèque et de sa version. Utilisez les réglages de prévention XXE correspondant à votre analyseur.
La SSRF est plus large. Prenons une fonction qui importe une image à partir d’une URL. Le serveur réalise lui-même la requête. S’il accepte n’importe quelle destination, il peut atteindre un service qui n’est normalement pas accessible aux visiteurs.
Il faut contrôler les destinations et protocoles autorisés, gérer les redirections et limiter les accès réseau sortants. La résolution des noms demande également de l’attention. Une simple vérification du début de l’URL est insuffisante. Le guide SSRF de l’OWASP détaille ces contrôles.
Une mauvaise configuration peut révéler vos données
Un site bien développé peut laisser une sauvegarde de base de données dans un dossier public. Un fichier de configuration oublié, un outil de test ou un ancien compte administrateur peuvent également exposer des informations.
Le fichier robots.txt ne protège pas ces ressources. Il donne des consignes d’exploration aux robots qui les respectent. Il ne bloque pas la consultation d’un document et ne remplace jamais une restriction d’accès sur le serveur.
Garder les erreurs détaillées dans des journaux privés
Une erreur PHP peut révéler le chemin complet d’un fichier. On parle de Full Path Disclosure. Cette information peut faciliter d’autres recherches, mais ne donne pas, à elle seule, accès au contenu du serveur.
En production, l’objectif est de journaliser les détails tout en présentant un message sobre au visiteur. Selon l’hébergement, la configuration PHP correspondante peut inclure ces directives.
display_errors = Off
display_startup_errors = Off
log_errors = On
Le journal doit être enregistré dans un emplacement privé. Après modification, vérifiez le comportement réel de l’application, car elle peut avoir sa propre gestion des erreurs. L’OWASP décrit cette séparation entre messages publics et diagnostics internes.
Les extensions et composants vulnérables
Une faille peut se trouver dans WordPress, un thème, une extension ou une bibliothèque utilisée par le développeur. Commencez par identifier la version réellement installée et l’avis de sécurité correspondant.
Lorsqu’un correctif maintenu existe, préparez une sauvegarde, appliquez la mise à jour et vérifiez les fonctions essentielles. Si aucun correctif n’est disponible, l’éditeur peut proposer une mesure temporaire. Selon le risque, il faut parfois désactiver le composant ou le remplacer.
Supprimez également les outils devenus inutiles. Ils augmentent le nombre de composants à suivre sans rendre de service. La gestion des dépendances vulnérables décrite par l’OWASP repose sur cet inventaire et sur le suivi des corrections.
Une mise à jour peut fermer la porte d’entrée. Elle ne supprime pas forcément un fichier malveillant ou un compte ajouté avant son installation. Des signes de piratage demandent donc une investigation complémentaire.
L’injection CRLF perturbe les en-têtes ou les journaux
CR et LF désignent des caractères de retour à la ligne. Ils peuvent poser problème lorsqu’une donnée contrôlée par un utilisateur est insérée sans précaution dans un en-tête HTTP ou dans un journal.
Dans un en-tête vulnérable, une rupture de ligne peut changer la structure attendue de la réponse. Dans un journal, elle peut créer des entrées trompeuses. Les mécanismes et les conséquences sont différents, même si les caractères en cause se ressemblent.
Utilisez les API d’en-têtes du framework, validez les valeurs attendues et refusez les retours à la ligne là où ils n’ont aucune raison d’être. Pour les journaux, préférez des données structurées avec un encodage adapté. La fiche CWE-113 décrit le cas des en-têtes HTTP.
Comment détecter les failles de votre propre site
Commencez par ce que vous pouvez vérifier sans provoquer d’incident. Recensez les composants, leurs versions, les comptes disposant de droits élevés et les fonctions sensibles. Un espace client, un paiement et un formulaire d’envoi de fichiers ne demandent pas les mêmes contrôles.
Consultez ensuite les journaux de l’application et de l’hébergement. Cherchez les événements inhabituels, notamment les créations de comptes, les modifications de fichiers et les connexions inattendues. Si Google signale un problème, le rapport de sécurité de Search Console peut orienter les recherches. Il ne constitue pas un audit de toutes les vulnérabilités.
Utiliser les scanners sans leur demander l’impossible
Un test en ligne peut repérer certains fichiers exposés, réglages ou versions connues. Un outil spécialisé peut aller plus loin, surtout lorsqu’il connaît les fonctions authentifiées de l’application. Gardez toutefois les conclusions à la hauteur de ce qui a réellement été testé.
Pour WordPress, WPScan peut rapprocher les versions identifiées des vulnérabilités répertoriées dans sa base. Il aide à chercher un problème connu. Une erreur propre à votre espace client peut lui échapper.
Pour une application web, ZAP propose notamment des tests actifs. Ce type d’analyse envoie des requêtes de test au serveur et demande un périmètre maîtrisé. Il ne faut pas le confondre avec la simple observation des pages que vous consultez.
Un scanner peut produire un faux positif ou manquer une erreur métier. Pour les tests qui envoient des requêtes inhabituelles, utilisez votre préproduction, des données fictives et un périmètre autorisé. Vérifiez aussi les conditions de votre hébergement.
L’OWASP Web Security Testing Guide aide à organiser les vérifications. Le plus parlant reste souvent un test précis, comme confirmer qu’un client ne peut pas consulter les factures d’un autre.
Corriger dans le bon ordre
Si vous découvrez une vulnérabilité sans signe de compromission, identifiez la fonction concernée et son exposition. Priorisez les failles qui touchent des données sensibles, des permissions élevées ou une fonction accessible publiquement, en tenant compte d’une exploitation connue.
Appliquez ensuite le correctif adapté, testez le cas qui posait problème et vérifiez les usages normaux. Une correction qui bloque un formulaire légitime mérite d’être ajustée avant remise en service.
Si le site est déjà piraté, il faut aussi traiter l’incident. Limitez l’accès à la fonction touchée ou isolez le site selon la gravité, puis préservez les journaux et les fichiers utiles à l’analyse. Évitez d’effacer immédiatement tout ce qui pourrait expliquer l’entrée de l’attaquant.
Le nettoyage doit être accompagné de la correction de cette entrée et d’un contrôle des accès. Depuis un environnement sain, révoquez les sessions et renouvelez les secrets concernés. Une sauvegarde n’est utile à la restauration que si elle est saine et si la faille est corrigée.
La fiche de Cybermalveillance.gouv.fr sur les sites défigurés fournit les premiers réflexes. Pour WordPress, une réparation du site piraté avec nettoyage et sécurisation permet de traiter ensemble les traces de l’intrusion et sa cause.
Les protections à garder en place sur WordPress
Je vous conseille de partir d’une base simple à suivre. Gardez WordPress, les thèmes et les extensions maintenus, retirez les composants inutiles et vérifiez les sauvegardes en réalisant une restauration de test. Une archive jamais testée donne peu de certitudes au moment où vous en avez besoin.
Attribuez à chaque personne les droits nécessaires à son travail. Un rédacteur n’a généralement pas besoin d’un compte administrateur. Protégez les accès sensibles avec un mot de passe unique et un second facteur, puis retirez les comptes qui ne servent plus.
Pour les développements spécifiques, utilisez les fonctions de sécurité prévues par WordPress. Les sorties, les requêtes SQL, les permissions et les nonces répondent à des besoins différents. Une extension de sécurité ne dispense pas de ces contrôles.
La documentation de durcissement WordPress donne une base de travail. Complétez-la par une surveillance des modifications et des alertes utiles, avec une personne clairement chargée d’y répondre.
Pour approfondir avec les références techniques
Les documentations liées dans chaque section permettent de retrouver les contrôles adaptés au langage ou au composant concerné. L’OWASP Top Ten offre un panorama des risques applicatifs, tandis que ses fiches de prévention détaillent les corrections. Utilisez ces références avec la documentation de votre framework et de votre hébergeur pour vérifier les réglages réellement disponibles.
Les questions fréquentes sur la sécurité d’un site
Peut-on trouver les failles d’un site gratuitement ?
Oui, certains outils gratuits permettent un premier contrôle des versions, de la configuration ou des réponses publiques. Ils peuvent aider à repérer un problème précis. Les droits d’accès, les fonctions connectées et les règles métier demandent souvent des vérifications complémentaires.
Un site en HTTPS peut-il être piraté ?
Oui. HTTPS chiffre le transport des données, mais une vulnérabilité peut se trouver dans le code ou la gestion des comptes. Une application reste exposée si elle donne accès à la facture d’un autre client ou utilise une extension vulnérable.
Quelle différence entre une faille XSS et une injection SQL ?
Une XSS fait interpréter un contenu comme du code dans le navigateur. Une injection SQL modifie une instruction adressée à la base de données. Les protections diffèrent également, avec un échappement adapté au contexte d’affichage pour la première et des requêtes préparées pour la seconde.
Un pare-feu suffit-il à protéger le site ?
Un pare-feu applicatif peut filtrer certaines tentatives et fournir une protection temporaire. Il ne corrige pas le code et ne comprend pas toutes les règles de votre application. Les mises à jour, les permissions et les corrections restent nécessaires.
Une extension de sécurité WordPress détecte-t-elle toutes les failles ?
Non. Selon ses fonctions, elle peut surveiller des fichiers, signaler des versions vulnérables ou limiter certaines attaques. Elle ne garantit pas la détection de toutes les failles, notamment dans un développement spécifique. Vérifiez ce qu’elle couvre avant d’interpréter son rapport.
Comment vérifier qu’une faille est corrigée ?
Reproduisez le cas qui révélait le problème sur un environnement maîtrisé. La demande indésirable doit être refusée, tandis que l’usage normal doit continuer à fonctionner. Contrôlez les fonctions similaires et surveillez les journaux après la mise en ligne du correctif.
Jai perdu mon mots de passe pour mon adresses imail
tu peux precisé
Faille d’un site de paiement de coupon
C’est vraiment génial