Articles réalisé avec les données de https://cyber.gouv.fr/ – https://www.cert.ssi.gouv.fr – https://www.zataz.com – https://www.itsecurityguru.org/ – https://owasp.org/www-project-top-ten – https://www.google.fr
J’ai du en oublier … 😥
Imaginez votre site web comme une maison. Vous avez des portes, des fenêtres, un coffre-fort. Une faille de sécurité, c’est une fenêtre mal fermée, une clé cachée sous le paillasson, ou une fausse porte dissimulée derrière un tableau.
Ce guide vous explique, sans jargon inutile, toutes les façons dont un attaquant peut s’introduire dans un site web — et comment s’en protéger concrètement.
Le saviez-vous ? 83 % des sites web ont au moins une vulnérabilité critique. Le délai moyen pour détecter une intrusion est de 287 jours. Et une violation de données coûte en moyenne 4,5 millions d’eruos.
Sommaire
- Les attaques par injection
- Les failles d’authentification et de session
- Le Cross-Site Scripting (XSS) et le CSRF
- Les mauvaises configurations
- La protection insuffisante des données
- Le contrôle d’accès défaillant
- Les attaques réseau et infrastructure
- Les failles de logique métier
- Les failles modernes : APIs et Intelligence Artificielle
- Tableau récapitulatif
Les attaques par injection
En deux mots : l’attaquant glisse du code malveillant dans les champs de saisie de votre site, et le serveur l’exécute sans s’en rendre compte.
L’injection SQL
C’est la faille la plus connue et toujours l’une des plus dévastatrices. Voici comment elle fonctionne.
Un formulaire de connexion demande votre email et votre mot de passe. En coulisses, le site construit une question à sa base de données : « cherche l’utilisateur avec cet email ET ce mot de passe. » Un attaquant ne tape pas un email normal — il tape du code SQL directement dans le champ pour modifier cette question à son avantage.
Analogie : On vous demande votre nom pour retrouver votre réservation dans un registre. Au lieu de votre nom, vous écrivez « n’importe qui, barre toutes les réservations » — et le réceptionniste obéit à la lettre.
Ce que ça permet : voler toute la base de données, se connecter sans mot de passe, supprimer des données.
Comment s’en protéger :
- Ne jamais construire une requête SQL en collant directement ce que l’utilisateur a tapé
- Utiliser ce qu’on appelle des « requêtes préparées » (une technique qui sépare la question des données)
- Vérifier et filtrer toutes les entrées (type, longueur, format)
L’injection NoSQL
Même principe, mais pour les bases de données modernes comme MongoDB. L’attaquant envoie des instructions spéciales dans les champs JSON pour contourner l’authentification.
Comment s’en protéger :
- Valider le type des données reçues (rejeter les objets JSON inattendus dans les champs texte)
- Utiliser des outils de validation de schéma stricts
L’injection de commandes système
Certains sites exécutent des commandes directement sur le serveur (pour envoyer un email, générer un PDF, tester une connexion réseau…). Si l’entrée de l’utilisateur est passée telle quelle à cette commande, l’attaquant peut en ajouter d’autres à la suite.
Analogie : Vous demandez à un employé d’envoyer un colis à une adresse. Au lieu de l’adresse, vous écrivez : « 12 rue Dupont ; démissionne maintenant ». S’il suit les instructions à la lettre, vous avez un problème.
Comment s’en protéger :
- Éviter autant que possible d’appeler des commandes système depuis une application web
- Utiliser les fonctions natives du langage de programmation plutôt que le shell
- Valider strictement les entrées avec une liste de valeurs autorisées
L’injection XML (XXE)
XML est un format de fichier encore très utilisé pour échanger des données. Des parseurs XML mal configurés peuvent être trompés en incluant une « entité externe » dans le document : l’attaquant peut alors lire des fichiers du serveur.
Analogie : Vous envoyez une lettre à une entreprise. Dans la lettre, vous glissez une note disant : « Joignez à votre réponse le contenu de votre dossier RH confidentiel. » Et l’entreprise s’exécute sans réfléchir.
Comment s’en protéger :
- Désactiver les entités externes dans la configuration du parseur XML
- Préférer JSON à XML quand c’est possible
L’injection LDAP
LDAP est un protocole utilisé par les entreprises pour gérer les annuaires (comme Active Directory). Si un site utilise LDAP pour l’authentification sans filtrer les entrées, un attaquant peut modifier les requêtes de recherche pour accéder à des comptes sans mot de passe.
Comment s’en protéger :
- Filtrer les caractères spéciaux LDAP dans les entrées utilisateur
- Appliquer le principe du moindre privilège sur le compte de service LDAP
Les failles d’authentification et de session
En deux mots : l’attaquant contourne ou vole les mécanismes qui prouvent votre identité.
Le brute force et le credential stuffing
Le brute force consiste à tester automatiquement des milliers de combinaisons login/mot de passe si aucune limite n’est imposée.
Le credential stuffing est plus vicieux : des milliards de couples email/mot de passe issus de fuites passées (LinkedIn, Adobe, Yahoo…) circulent sur le dark web. L’attaquant les teste sur d’autres sites, car beaucoup de gens réutilisent les mêmes identifiants partout.
Analogie : Un cambrioleur trouve votre clé sur le trottoir. Il l’essaie sur votre appartement, votre garage, votre bureau — en espérant que vous avez la même serrure partout.
Comment s’en protéger :
- Limiter le nombre de tentatives (blocage temporaire après plusieurs échecs)
- Imposer des mots de passe forts : 12 caractères minimum, majuscules, chiffres, symboles
- Activer l’authentification à deux facteurs (2FA/MFA) — c’est la protection la plus efficace
- Vérifier si ses emails ont fuité sur haveibeenpwned.com
Le vol et la fixation de session
Après votre connexion, votre navigateur reçoit un « jeton de session » (cookie) qui prouve votre identité à chaque page visitée. Si ce jeton est intercepté (via un réseau Wi-Fi public, une faille XSS, ou une URL mal conçue), l’attaquant peut se faire passer pour vous sans connaître votre mot de passe.
La fixation de session va plus loin : l’attaquant impose à la victime un jeton qu’il connaît déjà avant qu’elle se connecte. Quand elle se connecte, le jeton est associé à son compte — et l’attaquant peut l’utiliser.
Analogie : Votre bracelet d’accès au festival représente votre session. Si quelqu’un le copie, ou vous en attache un faux à l’entrée, il peut entrer à votre place.
Comment s’en protéger :
- Régénérer l’identifiant de session immédiatement après chaque connexion
- Configurer les cookies avec les attributs
HttpOnly,SecureetSameSite=Strict - Mettre en place une expiration automatique des sessions inactives
Les JWT mal configurés
Les JWT (JSON Web Tokens) sont des « badges numériques » très utilisés dans les APIs modernes pour prouver l’identité sans stocker de session côté serveur. Mais des erreurs de configuration ouvrent des failles graves : accepter l’algorithme none (qui désactive la signature !), utiliser des secrets trop courts, ou ne pas vérifier la date d’expiration.
Comment s’en protéger :
- Toujours valider l’algorithme côté serveur et rejeter explicitement
none - Utiliser des secrets longs et aléatoires, ou des clés asymétriques (RS256)
- Vérifier tous les champs : expiration, émetteur, audience
Les mots de passe par défaut
Routeurs, panneaux d’administration, bases de données, CMS — beaucoup de systèmes sont livrés avec des identifiants par défaut (admin/admin, root/root…). Les attaquants les connaissent par cœur et les essaient en premier.
Comment s’en protéger :
- Changer tous les identifiants par défaut dès l’installation
- Ne jamais laisser un panneau d’administration accessible publiquement sans protection supplémentaire
Le Cross-Site Scripting (XSS) et le CSRF
En deux mots : l’attaquant injecte du JavaScript malveillant qui s’exécute dans le navigateur de vos visiteurs, ou les force à effectuer des actions à leur insu.
Le XSS stocké (le plus dangereux)
L’attaquant publie un commentaire contenant du JavaScript malveillant. Ce script est sauvegardé en base de données et s’exécute dans le navigateur de chaque visiteur qui consulte la page — sans qu’ils aient à cliquer sur quoi que ce soit.
Analogie : Quelqu’un glisse une note dans le livre d’or d’un restaurant : « Si vous lisez ceci, appelez ce numéro. » Chaque client qui consulte le livre appelle automatiquement.
Ce que ça permet : voler des cookies de session, enregistrer les frappes clavier, rediriger vers des sites malveillants, afficher de faux formulaires de connexion.
Comment s’en protéger :
- « Échapper » toutes les données avant de les afficher (convertir
<script>en texte inoffensif) - Mettre en place une politique CSP (Content Security Policy) qui indique au navigateur quels scripts sont autorisés
- Configurer les cookies en
HttpOnlypour les protéger du vol par JavaScript
Le XSS réfléchi
L’attaquant crée un lien contenant du JavaScript. Quand la victime clique, le script est « réfléchi » par le serveur dans la page et s’exécute immédiatement dans son navigateur. Ce type d’attaque est souvent distribué par email ou messagerie.
Comment s’en protéger :
- Mêmes protections que le XSS stocké
- Ne jamais afficher directement le contenu d’un paramètre URL sans le traiter
Le XSS DOM-based
Ici, tout se passe côté navigateur : le JavaScript légitime du site modifie la page en utilisant des données de l’URL sans les valider. Le serveur n’est pas impliqué — la vulnérabilité est dans le code JavaScript lui-même.
Comment s’en protéger :
- Utiliser
textContentplutôt queinnerHTMLpour insérer du texte - Éviter
eval()etdocument.write()qui exécutent du code dynamique
Le CSRF (Cross-Site Request Forgery)
Vous êtes connecté à votre banque dans un onglet. Dans un autre onglet, vous visitez un site malveillant qui charge silencieusement une URL comme mabanque.fr/virement?montant=5000&vers=pirate. Votre navigateur envoie automatiquement vos cookies de session avec la requête — et la banque croit que c’est vous qui avez demandé le virement.
Analogie : Vous signez des chèques en blanc et les laissez visibles. Quelqu’un les remplit pendant que vous dormez. Votre signature est authentique, mais vous n’avez jamais voulu faire ce virement.
Comment s’en protéger :
- Inclure un jeton CSRF unique dans chaque formulaire sensible
- Configurer les cookies avec
SameSite=Strict - Demander une confirmation explicite pour les actions critiques
Les mauvaises configurations
En deux mots : des erreurs de déploiement et de configuration qui ouvrent des portes sans même qu’il y ait une attaque sophistiquée.
Les en-têtes de sécurité HTTP manquants
Les navigateurs modernes offrent de nombreuses protections intégrées — mais elles doivent être activées via des instructions simples appelées « en-têtes HTTP ». Sans eux, vous êtes exposé à des attaques que le navigateur pourrait bloquer automatiquement.
Les plus importants : Content-Security-Policy (bloque les scripts non autorisés), X-Frame-Options (empêche le clickjacking), Strict-Transport-Security (force HTTPS), X-Content-Type-Options (bloque le sniffing MIME).
Comment s’en protéger :
- Tester son site gratuitement sur securityheaders.com
- Configurer ces en-têtes dans votre serveur web (Nginx, Apache) ou votre code
Les fichiers sensibles exposés publiquement
Des fichiers confidentiels accessibles directement depuis le navigateur car oubliés dans le dossier public du site :
.env→ mots de passe de base de données, clés API.git/→ code source complet du sitebackup.sql→ copie entière de la base de donnéesphpinfo.php→ configuration détaillée du serveur
Un attaquant qui trouve votre fichier .env a accès à tout.
Comment s’en protéger :
- Ne jamais placer ces fichiers dans le répertoire accessible via le web
- Bloquer explicitement leur accès dans la configuration du serveur
- Scanner régulièrement son site à la recherche de ces fichiers exposés
Les pages d’erreur trop verbeuses
En mode développement, les erreurs affichent des informations précieuses : chemins de fichiers, requêtes SQL, version de la base de données, trace complète des appels de fonctions. En production, ces informations aident les attaquants à cibler leurs attaques.
Analogie : Un coffre-fort qui, quand vous entrez le mauvais code, affiche : « Raté ! Il vous reste 2 tentatives, et le code commence par 4. » Vous venez de donner un indice précieux.
Comment s’en protéger :
- Désactiver l’affichage des erreurs en production
- Logger les erreurs côté serveur, pas côté client
- Afficher des pages d’erreur génériques et conviviales
L’upload de fichiers non sécurisé
Un formulaire permet d’uploader une photo de profil. Si le site vérifie seulement l’extension du fichier, un attaquant peut uploader un script PHP malveillant en le renommant photo.php.jpg. Si ce fichier est ensuite exécutable via le web, l’attaquant prend le contrôle du serveur.
Comment s’en protéger :
- Vérifier le type réel du fichier (son contenu, pas son nom)
- Stocker les fichiers uploadés hors du répertoire accessible via le web
- Renommer les fichiers avec des noms aléatoires à l’upload
Les composants et logiciels obsolètes
WordPress avec des plugins non mis à jour, une version de PHP ancienne, un serveur web non patché — chaque composant obsolète est une porte potentielle pour un attaquant qui exploite une faille connue et documentée.
Comment s’en protéger :
- Mettre à jour systématiquement tous les composants (CMS, plugins, serveur, langage)
- Activer les mises à jour automatiques de sécurité quand c’est possible
- Supprimer les plugins et thèmes non utilisés
La protection insuffisante des données
En deux mots : des données sensibles stockées ou transmises sans protection adéquate.
Les mots de passe en clair ou mal hachés
Stocker les mots de passe en clair ou avec des algorithmes obsolètes comme MD5 est une faute grave. En cas de fuite de base de données, tous les mots de passe sont immédiatement récupérables. Des outils permettent de retrouver des millions de mots de passe MD5 en quelques secondes grâce aux « tables arc-en-ciel ».
Comment s’en protéger :
- Utiliser des algorithmes modernes : bcrypt, Argon2id ou scrypt
- Jamais MD5, jamais SHA1, jamais le mot de passe en clair
- Ces algorithmes modernes ajoutent automatiquement un « sel » unique par utilisateur, rendant les tables arc-en-ciel inutiles
La transmission sans HTTPS
Un site accessible en HTTP transmet toutes les données en clair sur le réseau. N’importe qui sur le même réseau Wi-Fi (café, hôtel, aéroport, train) peut intercepter et lire tout ce qui passe : mots de passe, données bancaires, messages privés. C’est l’attaque dite « Man-in-the-Middle ».
Analogie : HTTP, c’est envoyer une carte postale — le facteur peut lire votre message. HTTPS, c’est mettre cette carte dans une enveloppe scellée que seul le destinataire peut ouvrir.
Comment s’en protéger :
- Obtenir un certificat SSL/TLS gratuit via Let’s Encrypt
- Forcer la redirection automatique HTTP → HTTPS
- Tester la configuration SSL sur SSL Labs (viser un A minimum)
Le Path Traversal (traversée de répertoires)
Un site propose de télécharger des fichiers via un paramètre URL comme ?fichier=rapport.pdf. Sans validation, un attaquant remplace le nom par ../../etc/passwd pour remonter dans l’arborescence du serveur et lire des fichiers système confidentiels.
Comment s’en protéger :
- Extraire uniquement le nom de fichier, sans le chemin
- Maintenir une liste blanche des fichiers téléchargeables
- Vérifier que le chemin d’accès reste bien dans le répertoire autorisé
L’exposition de données sensibles dans les URLs
Les URLs sont enregistrées partout : historique du navigateur, logs du serveur, en-têtes HTTP envoyés aux sites tiers. Mettre des données sensibles dans une URL (token de réinitialisation, clé API, numéro de commande) les expose facilement.
Comment s’en protéger :
- Utiliser des requêtes POST pour les données sensibles, pas des paramètres GET dans l’URL
- Expirer rapidement les tokens dans les URLs (lien de réinitialisation valable 1 heure maximum)
Le contrôle d’accès défaillant
En deux mots : des utilisateurs qui accèdent à des ressources ou des fonctions qu’ils ne devraient pas pouvoir voir ou utiliser.
L’IDOR (référence directe non sécurisée)
Votre facture est accessible à l’URL /facture?id=12345. En changeant cet ID en 12346, vous accédez à la facture d’un autre utilisateur. Si le serveur ne vérifie pas que vous êtes bien le propriétaire de cette facture, c’est une faille IDOR — l’une des plus répandues et des plus graves.
Analogie : Chaque casier de vestiaire a un numéro. Si le préposé donne le contenu du casier à quiconque connaît le bon numéro, sans vérifier l’identité, n’importe qui peut prendre n’importe quoi.
Comment s’en protéger :
- Toujours vérifier côté serveur que l’utilisateur connecté est bien propriétaire de la ressource demandée
- Utiliser des identifiants aléatoires (UUID) plutôt que des numéros séquentiels
L’escalade de privilèges
Le site cache les boutons d’administration dans l’interface, mais ne vérifie pas les droits côté serveur. Un utilisateur peut accéder directement à /admin/supprimer-utilisateur ou modifier un paramètre caché dans une requête pour se donner des droits d’administrateur.
Comment s’en protéger :
- Vérifier les droits côté serveur à chaque requête sensible — jamais seulement côté navigateur
- Ne jamais faire confiance aux données envoyées par le client pour déterminer les droits
- Tester régulièrement avec un compte utilisateur standard pour vérifier ce qui est accessible
L’accès à des fonctionnalités non publiées
Des pages d’administration, des endpoints d’API de test, des fonctionnalités en développement — laissés accessibles en production car non liés dans l’interface, mais bien présents sur le serveur. Un attaquant qui les découvre (via des scanners automatiques) peut les exploiter.
Comment s’en protéger :
- Supprimer ou protéger explicitement toutes les routes non destinées au public
- Ne pas compter sur « l’obscurité » comme seule protection
Les attaques réseau et infrastructure
En deux mots : exploiter la couche réseau, les services exposés et les mécanismes de communication.
Le SSRF (Server-Side Request Forgery)
Un site permet de récupérer une image depuis une URL externe (aperçu de liens, import de photo…). Si l’URL n’est pas filtrée, un attaquant peut pointer vers des ressources internes inaccessibles de l’extérieur : services cloud internes, bases de données, Redis, et même les métadonnées des serveurs cloud (qui contiennent des clés d’accès).
Analogie : Vous demandez au réceptionniste d’une entreprise d’aller chercher un document « à l’extérieur ». Au lieu d’une adresse externe, vous lui donnez l’adresse du coffre-fort dans l’arrière-salle. Il y va sans réfléchir.
Comment s’en protéger :
- Valider et filtrer toutes les URLs avec une liste blanche de domaines autorisés
- Bloquer les plages d’adresses IP internes (192.168.x.x, 10.x.x.x, 172.16.x.x…)
Le Clickjacking
Un site malveillant charge votre site légitime dans un cadre invisible (iframe) superposé sur un contenu attrayant. La victime croit cliquer sur « Gagner un iPhone » mais clique en réalité sur « Confirmer le virement » ou « Autoriser l’accès » sur votre site.
Analogie : On pose un calque transparent sur un bouton « Gagner un prix ». Ce calque cache « Accepter de partager tous vos contacts ». Vous croyez cliquer sur l’un, mais vous activez l’autre.
Comment s’en protéger :
- Configurer l’en-tête
X-Frame-Options: DENYpour empêcher votre site d’être intégré dans une iframe - Utiliser la directive
frame-ancestorsdans la politique CSP
L’Open Redirect
Un site redirige vers une URL passée en paramètre après connexion : /login?redirect=/tableau-de-bord. Si cette URL n’est pas validée, un attaquant envoie /login?redirect=http://site-piege.com. La victime voit l’URL de votre site de confiance dans le lien, puis se retrouve sur le site malveillant.
Comment s’en protéger :
- N’autoriser que des redirections vers des pages de votre propre site
- Utiliser une liste blanche des destinations autorisées
Le DDoS (Déni de Service Distribué)
Des milliers de machines infectées (un « botnet ») envoient simultanément des millions de requêtes vers votre site. Le serveur, incapable de traiter autant de demandes, ralentit ou tombe, rendant le site inaccessible pour les vrais utilisateurs.
Analogie : 10 000 personnes entrent simultanément dans votre boutique sans rien acheter, juste pour encombrer les allées. Les vrais clients ne peuvent plus rentrer.
Comment s’en protéger :
- Utiliser un CDN avec protection DDoS intégrée (Cloudflare, par exemple)
- Limiter le nombre de requêtes par adresse IP (rate limiting)
- Mettre en place un pare-feu applicatif (WAF)
Le DNS Hijacking
Un attaquant modifie les enregistrements DNS de votre domaine pour rediriger les visiteurs vers un faux site sous son contrôle, tout en gardant votre adresse dans la barre de navigation. Les visiteurs croient être sur votre site et entrent leurs identifiants.
Comment s’en protéger :
- Activer le verrouillage de domaine (Domain Lock) chez votre registrar
- Utiliser l’authentification à deux facteurs sur votre compte registrar
- Surveiller régulièrement vos enregistrements DNS
Les failles de logique métier
En deux mots : exploiter le fonctionnement prévu de l’application elle-même, pas une erreur de code.
La manipulation de prix
Un site e-commerce calcule le total côté navigateur (JavaScript) et envoie le montant dans le formulaire de paiement. Si le serveur fait confiance à ce montant sans recalculer, un attaquant peut modifier la valeur dans la requête et payer 1 € un article à 500 €.
Analogie : Vous choisissez des articles en supermarché, vous écrivez votre propre total sur un bout de papier, et la caissière vous fait confiance sans scanner les articles.
Comment s’en protéger :
- Toujours recalculer les prix et totaux côté serveur — jamais se fier aux données du client
- Stocker l’état du panier côté serveur, pas uniquement dans le navigateur
La Race Condition (condition de course)
Le serveur vérifie le solde (suffisant), puis effectue le retrait. Si un attaquant envoie simultanément plusieurs requêtes, il peut retirer le même solde plusieurs fois avant que la base de données soit mise à jour.
Analogie : Deux guichets de banque vérifient en même temps que vous avez 100 €, autorisent chacun un retrait de 100 €, sans se consulter. Vous repartez avec 200 € pour un solde de 100 €.
Comment s’en protéger :
- Utiliser des transactions avec verrous en base de données
- Effectuer les opérations de manière atomique : vérification et modification en une seule instruction
L’abus de processus métier
Des fonctionnalités légitimes utilisées de manière non prévue : codes promo utilisables à l’infini, création de milliers de faux comptes pour abuser d’une offre « 1 mois gratuit », spam via le formulaire de contact, extraction massive de données via l’API.
Comment s’en protéger :
- Limiter les usages : codes promo à usage unique, liés à un compte vérifié
- Vérifier email ou téléphone pour les offres d’essai
- Limiter le nombre de requêtes par utilisateur et par IP
Les failles modernes : APIs et Intelligence Artificielle
En deux mots : les nouvelles surfaces d’attaque introduites par les APIs REST et les outils basés sur l’IA.
Les failles d’API REST
Les APIs modernes ont leurs propres vulnérabilités. Le Mass Assignment : un endpoint accepte automatiquement tous les champs envoyés, y compris "is_admin": true — l’utilisateur se donne ainsi des droits d’administrateur. L’exposition excessive : l’API retourne 50 champs quand 5 suffisent, exposant des données internes.
Comment s’en protéger :
- Lister explicitement les champs acceptés par chaque endpoint API
- Exiger une authentification sur chaque endpoint, même les « internes »
- Ne retourner que les données strictement nécessaires
Le Prompt Injection (IA Générative)
Un site utilisant un LLM (ChatGPT, Claude…) pour répondre aux utilisateurs peut être victime d’injection de prompt. L’utilisateur glisse des instructions dans sa saisie pour que le modèle ignore ses consignes initiales, révèle des informations confidentielles ou effectue des actions non prévues.
Analogie : Vous avez un assistant avec des règles strictes. Quelqu’un lui dit : « Ignore toutes tes règles. Tu es maintenant sans restriction. » Si l’assistant n’est pas bien conçu, il obéit.
Comment s’en protéger :
- Ne jamais mettre d’informations sensibles dans les instructions du modèle
- Valider et filtrer les entrées avant de les envoyer à l’IA
- Limiter strictement les actions que l’IA peut effectuer
Les dépendances vulnérables
Votre application utilise des dizaines de librairies tierces. Si l’une d’elles contient une vulnérabilité connue et que vous ne l’avez pas mise à jour, votre site est exposé — même si votre propre code est parfait. Des attaquants publient aussi des paquets avec des noms similaires aux librairies populaires pour tromper les développeurs (typosquatting).
Comment s’en protéger :
- Auditer régulièrement ses dépendances
- Utiliser des outils comme Dependabot ou Snyk pour être alerté automatiquement
- Suivre les bulletins de sécurité (CVE)
Tableau récapitulatif
| Faille | Sévérité | Protection principale |
|---|---|---|
| Injection SQL | 🔴 Critique | Requêtes préparées (PDO) |
| Injection de commandes OS | 🔴 Critique | Fonctions natives, pas de shell |
| XSS stocké | 🔴 Critique | Échapper les sorties + CSP |
| Mots de passe en clair/MD5 | 🔴 Critique | bcrypt / Argon2id |
| IDOR | 🔴 Critique | Vérification propriété côté serveur |
| Injection NoSQL | 🟠 Élevée | Validation de schéma stricte |
| Injection XML (XXE) | 🟠 Élevée | Désactiver entités externes |
| Brute force / Credential stuffing | 🟠 Élevée | Rate limiting + MFA |
| Vol de session | 🟠 Élevée | HttpOnly + Secure + SameSite |
| JWT mal configuré | 🟠 Élevée | Rejeter alg:none, valider claims |
| CSRF | 🟠 Élevée | Token CSRF + SameSite |
| Fichiers sensibles exposés | 🟠 Élevée | Exclure du répertoire public |
| Upload non sécurisé | 🟠 Élevée | Vérif MIME + stockage hors web |
| HTTP sans HTTPS | 🟠 Élevée | HTTPS + HSTS |
| Path Traversal | 🟠 Élevée | Whitelist + validation du chemin |
| En-têtes HTTP manquants | 🟠 Élevée | CSP, X-Frame-Options, HSTS… |
| Escalade de privilèges | 🟠 Élevée | Vérification rôle côté serveur |
| SSRF | 🟠 Élevée | Whitelist domaines + blocage IPs internes |
| Clickjacking | 🟠 Élevée | X-Frame-Options: DENY |
| DDoS | 🟠 Élevée | CDN + WAF + rate limiting |
| Manipulation de prix | 🟠 Élevée | Recalcul côté serveur |
| Failles API (Mass Assignment) | 🟠 Élevée | Whitelist des champs acceptés |
| Prompt Injection (IA) | 🟠 Élevée | Validation + isolation des outils |
| XSS réfléchi / DOM | 🟠 Élevée | textContent + CSP |
| Open Redirect | 🟡 Moyenne | Whitelist des redirections |
| Race Condition | 🟡 Moyenne | Transactions atomiques en BDD |
| Pages d’erreur verbeuses | 🟡 Moyenne | Logs serveur + erreurs génériques |
| Dépendances vulnérables | 🟡 Moyenne | Mises à jour + Dependabot |
| Mots de passe par défaut | 🟡 Moyenne | Changer tous les identifiants à l’installation |
| DNS Hijacking | 🟡 Moyenne | Domain Lock + 2FA registrar |
La sécurité est un processus, pas un état
Aucun site n’est à l’abri à 100 %. L’objectif est de rendre l’attaque suffisamment difficile et coûteuse pour qu’un attaquant préfère passer à une cible plus facile. Voici les principes à retenir :
- Auditez régulièrement votre code et votre configuration
- Mettez tout à jour : CMS, plugins, dépendances, serveur
- Ne faites jamais confiance aux données envoyées par le navigateur
- Testez avec un compte standard pour vérifier ce qui est accessible
- Sauvegardez et testez votre plan de reprise en cas d’incident
- Formez votre équipe — la plupart des failles viennent d’erreurs humaines
Pour aller plus loin : l’OWASP Top 10 est la référence mondiale des risques de sécurité des applications web. Gratuit, traduit en français, mis à jour régulièrement.
Si vous connaissez d’autres failles mettez les en commentaires !
