Il y a trois ans, j'ai vu une startup pour laquelle je consultais perdre tout en 72 heures. Pas à cause d'une attaque sophistiquée d'un État-nation ou d'une exploitation de zero-day qui a fait la une des journaux. Ils ont perdu l'intégralité de leur base de données clients, leur réputation et finalement leur entreprise à cause d'une seule vulnérabilité d'injection SQL qu'un développeur junior a introduite lors d'un déploiement précipité un vendredi. L'attaque a eu lieu un lundi matin. Dans l'après-midi de mercredi, ils rédigeaient des documents de faillite.
💡 Points clés
- Le piège d'authentification qui prend tout le monde
- Le Cross-Site Scripting : La vulnérabilité qui ne meurt jamais
- Injection SQL : La vulnérabilité ancienne qui fonctionne encore
- HTTPS n'est plus optionnel
Je suis Sarah Chen, et j'ai passé les 12 dernières années en tant qu'architecte de sécurité dans des entreprises allant de startups peu structurées à des entreprises du Fortune 500. J'ai vu les mêmes erreurs évitables détruire des entreprises encore et encore. La partie frustrante ? La plupart de ces catastrophes auraient pu être évitées avec des connaissances de base en sécurité qui prennent moins de temps à apprendre que votre cadre JavaScript moyen.
Voici ce que personne ne vous dit lorsque vous apprenez à coder : la sécurité n'est pas un sujet avancé que vous abordez après avoir maîtrisé tout le reste. C'est fondamental. C'est comme apprendre à conduire sans comprendre que les feux rouges signifient s'arrêter. Vous pourriez vous en tirer un moment, mais finalement, vous allez provoquer un accident catastrophique.
Selon le rapport 2023 sur les enquêtes sur les violations de données de Verizon, 74 % des violations impliquaient l'élément humain, y compris les erreurs, l'utilisation abusive ou l'ingénierie sociale. Mais voici le hic : lorsqu'ils ont analysé spécifiquement les attaques des applications web, ils ont découvert que 86 % exploitaient des vulnérabilités qui avaient été documentées et évitables depuis plus d'une décennie. Nous ne perdons pas face à des attaquants sophistiqués. Nous perdons face à notre propre ignorance des bases.
Le piège d'authentification qui prend tout le monde
Laissez-moi vous parler de l'authentification, car c'est ici que je vois les développeurs faire leur première erreur critique. Ils le traitent comme une fonctionnalité à cocher plutôt que la fondation de l'ensemble de leur modèle de sécurité. J'ai une fois examiné du code où un développeur avait mis en œuvre l'authentification en vérifiant si l'email d'un utilisateur existait dans un cookie. Pas un cookie signé. Pas un token chiffré. Juste une adresse e-mail en texte clair que n'importe qui pouvait modifier dans les outils de développement de son navigateur.
Quand j'ai souligné cela, le développeur a dit : "Mais ça fonctionne !" Et c'est là le problème. Les vulnérabilités de sécurité ne se signalent pas avec des messages d'erreur. Elles fonctionnent parfaitement jusqu'à ce que quelqu'un les exploite.
Voici ce que nécessite réellement une authentification appropriée. Tout d'abord, vous devez comprendre la différence entre l'authentification (prouver qui vous êtes) et l'autorisation (prouver ce que vous êtes autorisé à faire). J'ai vu des systèmes de production où ces concepts étaient si embrouillés que résoudre un problème de sécurité en créait trois autres.
Le stockage des mots de passe est non négociable. Vous devez utiliser un véritable algorithme de hachage de mots de passe comme bcrypt, scrypt ou Argon2. Pas SHA-256. Pas MD5. Définitivement pas en texte clair. Je rencontre encore des bases de données en 2026 où les mots de passe sont stockés en texte clair, et chaque fois, le développeur me dit qu'il "ne pensait pas que quelqu'un essaierait réellement de les pirater." C'est comme laisser la porte d'entrée déverrouillée parce que vous ne pensez pas que quelqu'un oserait réellement vous cambrioler.
Les chiffres ici sont frappants. Selon le rapport 2023 du Centre de ressources sur le vol d'identité, il y a eu 3 205 compromissions de données affectant plus de 353 millions de victimes rien qu'aux États-Unis. Lorsque les chercheurs ont analysé les données compromises, ils ont découvert que dans les cas où les méthodes de stockage de mots de passe étaient divulguées, 43 % utilisaient un hachage inadéquat ou pas de hachage du tout.
La gestion des sessions est là où les choses deviennent intéressantes. Vous devez générer des tokens de session cryptographiquement sécurisés et aléatoires. Les générateurs de nombres aléatoires intégrés dans la plupart des langages ne sont pas cryptographiquement sécurisés. En Node.js, vous voulez crypto.randomBytes(), pas Math.random(). En Python, vous voulez secrets.token_hex(), pas random.random(). J'ai vu des tokens de session générés avec des timestamps et des IDs d'utilisateur concaténés ensemble. Un attaquant peut les prédire en quelques secondes.
Vos tokens de session devraient avoir au moins 128 bits d'entropie. Ils ne devraient être transmis que par HTTPS. Ils devraient avoir le drapeau HttpOnly activé afin que le JavaScript ne puisse pas y accéder. Ils devraient avoir le drapeau Secure activé afin qu'ils ne soient jamais envoyés sur des connexions non chiffrées. Ils devraient avoir l'attribut SameSite activé pour prévenir les attaques CSRF. Et ils devraient expirer. Je recommande 30 minutes d'inactivité pour des applications sensibles, peut-être 24 heures pour des scénarios à faible risque.
Le Cross-Site Scripting : La vulnérabilité qui ne meurt jamais
Les attaques XSS sont comme des cafards. Elles existent depuis toujours, tout le monde en parle, et pourtant elles continuent d'apparaître dans le code de production. Les vulnérabilités XSS font partie des 10 principales de l'OWASP depuis sa création en 2003, et elles y sont encore en 2026. Cela fait 21 ans de la même vulnérabilité évitable.
"La sécurité n'est pas un sujet avancé que vous abordez après avoir maîtrisé tout le reste. C'est fondamental. C'est comme apprendre à conduire sans comprendre que les feux rouges signifient s'arrêter."
Je me souviens d'auditer une application de santé qui affichait des notes de patients saisies par des médecins. Les développeurs avaient construit un éditeur de texte riche qui permettait un formatage de base. Cela semble raisonnable, non ? Sauf qu'ils prenaient cette entrée HTML et la rendaient directement sur la page sans aucune sanitisation. J'ai démontré la vulnérabilité en entrant une note de patient qui contenait une balise script. Ce script aurait pu voler des tokens de session, modifier des dossiers médicaux, ou exfiltrer des données de patients. Les développeurs étaient choqués. Ils n'avaient jamais envisagé qu'un médecin puisse être malveillant, ou qu'un ordinateur de médecin compromis puisse injecter du code malveillant.
Voici le principe fondamental : ne jamais faire confiance à l'entrée de l'utilisateur. Jamais. Ni aux médecins, ni aux administrateurs, ni à votre PDG. Chaque morceau de données provenant de l'extérieur de votre application est potentiellement malveillant jusqu'à preuve du contraire.
Il y a trois types de XSS que vous devez comprendre. Le XSS Stocké est lorsque du code malveillant est enregistré dans votre base de données et exécuté chaque fois que quelqu'un consulte ces données. Le XSS Réfléchi est lorsque du code malveillant dans un paramètre URL est immédiatement réfléchi dans la réponse. Le XSS basé sur le DOM est lorsque le JavaScript côté client prend l'entrée de l'utilisateur et l'insère dans la page sans sanitisation appropriée.
La solution n'est pas compliquée, mais elle nécessite de la discipline. Vous devez échapper la sortie en fonction du contexte. Si vous insérez des données dans un contenu HTML, vous avez besoin d'une échappement d'entités HTML. Si vous insérez des données dans une chaîne JavaScript, vous avez besoin d'une échappement JavaScript. Si vous insérez des données dans une URL, vous avez besoin d'un encodage URL. Si vous insérez des données dans du CSS, vous avez besoin d'une échappement CSS.
Les frameworks modernes aident à cela. React, Vue et Angular échappent tous la sortie par défaut. Mais ce ne sont pas de la magie. Si vous utilisez dangerouslySetInnerHTML dans React ou v-html dans Vue, vous contournez ces protections. J'ai vu des développeurs utiliser ces fonctionnalités parce qu'ils "devaient" rendre du HTML, sans comprendre qu'ils ouvraient une vulnérabilité XSS.
Le Content Security Policy est votre deuxième ligne de défense. CSP est un en-tête HTTP qui indique au navigateur quelles sources de contenu sont légitimes. Vous pouvez bloquer complètement les scripts en ligne, restreindre quels domaines peuvent charger du JavaScript, et prévenir toute une classe d'attaques XSS. Selon la recherche de Google, la mise en œuvre d'un CSP strict peut prévenir environ 95 % des attaques XSS. Pourtant, de mon expérience, moins de 30 % des applications que j'audite ont un CSP, et la plupart d'entre elles sont si permissives qu'elles sont essentiellement inutiles.
Injection SQL : La vulnérabilité ancienne qui fonctionne encore
L'injection SQL devrait être éteinte. Elle est bien comprise depuis les années 1990. Bobby Tables est devenu un mème depuis plus d'une décennie. Et pourtant, selon le rapport 2023 de l'État d'Internet d'Akamai, les tentatives d'injection SQL représentent 65 % de toutes les attaques d'applications web. Pourquoi ? Parce que ça fonctionne encore.
| Type de vulnérabilité | Niveau de risque | Difficulté de prévention | Cause commune |
|---|---|---|---|
| Injection SQL | Critique | Facile | Entrée utilisateur non sanitisée dans les requêtes |
| Authentification faible | Critique | Facile | Mauvaises politiques de mot de passe, pas de MFA |
| XSS (Cross-Site Scripting) | Élevé | Modéré | Contenu utilisateur non échappé dans le HTML |
| Contrôle d'accès brisé | Élevé | Modéré | Vérifications d'autorisation manquantes |
| Mauvaise configuration de sécurité | Moyen | Facile | Paramètres par défaut, points de terminaison exposés |
Une fois, j'ai consulté une entreprise de commerce électronique qui était en activité depuis huit ans. Ils avaient traité des millions de transactions. Ils avaient une équipe de 15 développeurs. Et leur fonctionnalité de recherche était vulnérable à l'injection SQL. Le code ressemblait à ceci : ils prenaient le terme de recherche à partir du paramètre URL et l'ajoutaient directement dans une requête SQL. Pas de paramétrage. Pas de validation d'entrée. Rien.
Lorsque j'ai démontré la vulnérabilité...