En 2017, Equifax s'est fait voler les données personnelles de près de 150 millions de personnes. Pas parce qu'un génie a percé leurs défenses : parce qu'une vulnérabilité déjà connue de leur framework web, publiée deux mois plus tôt, n'avait pas été corrigée. C'est le constat du rapport officiel du GAO américain sur cette brèche (GAO-18-559). La cybersécurité, ce n'est pas des casquettes noires et des écrans verts : ce sont des détails d'hygiène que la plupart des équipes négligent.

Les trois failles qui font 80 % des dégâts

L'OWASP publie tous les quelques années son Top 10 des risques applicatifs, et depuis vingt ans les mêmes familles reviennent en tête : injections, broken access control, erreurs cryptographiques. Le principe de l'injection SQL tient en une ligne : des données utilisateur deviennent du code. Si vous collez directement la saisie d'un formulaire dans une requête, un visiteur qui tape ' OR '1'='1 dans un champ peut contourner votre authentification.

// Vulnérable : la saisie devient du SQL
const req = "SELECT * FROM users WHERE email = '" + email + "'";

// Sûr : la saisie reste une valeur, jamais interprétée
const req = "SELECT * FROM users WHERE email = $1";
await db.query(req, [email]);

La défense est simple et systématique : des requêtes paramétrées, partout, sans exception. Toute bibliothèque sérieuse les propose, y compris quand la valeur doit apparaître dans un ORDER BY ou un nom de table (on liste alors les valeurs autorisées dans le code). Le guide de prévention OWASP dédié aux injections SQL détaille tous les cas, y compris les procédures stockées.

La XSS (Cross-Site Scripting) suit la même logique côté navigateur : un commentaire qui contient du JavaScript, affiché tel quel dans la page, s'exécute chez chaque visiteur. Un attaquant peut alors voler les cookies de session de vos utilisateurs, ou leur faire croire à un faux contenu légitime.

// Dangereux : HTML interprété
element.innerHTML = commentaireUtilisateur;

// Sûr : texte pur, rien ne s'exécute
element.textContent = commentaireUtilisateur;

Enfin, le CSRF exploite la confiance d'un site envers le navigateur de l'utilisateur : une page malveillante fait déclencher une action à votre place pendant que votre session est active, typiquement un virement ou un changement d'email. La défense standard : un jeton aléatoire joint à chaque formulaire sensible et vérifié côté serveur, complété aujourd'hui par l'attribut SameSite=Lax sur les cookies, que les frameworks modernes posent par défaut mais que tout le monde doit vérifier.

Mots de passe : arrêtez de les faire deviner

Le mot de passe le plus courant au monde reste « 123456 », première du classement six années sur sept selon l'étude annuelle de NordPass. Pire : après des années de fuites massives, des milliards de couples email/mot de passe circulent publiquement, et des robots les testent automatiquement sur tous les sites populaires. Si vos utilisateurs réutilisent un mot de passe fui ailleurs, votre site se fait compromettre sans qu'aucune de vos défenses soit percée. Le service Have I Been Pwned permet de vérifier gratuitement si une adresse a été touchée par une fuite connue.

const bcrypt = require("bcryptjs");

// À l'inscription : hacher lentement, volontairement
const hash = await bcrypt.hash(motDePasse, 12);

// À la connexion : comparer sans jamais stocker le mot de passe
const valide = await bcrypt.compare(proposition, hash);

Les règles côté application : hacher avec bcrypt ou argon2, jamais MD5 ni SHA1 nus ; imposer une longueur minimale plutôt que des règles byzantines de caractères spéciaux (une phrase de quatre mots aléatoires bat « P@ssw0rd! » à tous les coups) ; vérifier les nouveaux mots de passe contre les listes de fuites comme le recommande la feuille OWASP sur l'authentification ; proposer la double authentification par application (TOTP), pas par SMS, vulnérable au détournement de carte SIM. Côté utilisateurs, recommandez un gestionnaire de mots de passe : Bitwarden en ligne de mire pour les équipes, KeePassXC pour un coffre local.

Sessions et jetons : les détails qui tuent

Un JWT stocké dans localStorage est lisible par n'importe quel script injecté : une XSS, et toute la base client est compromise. Les cookies HttpOnly, que JavaScript ne peut pas lire, existent précisément pour ça. Ajoutez des durées de vie courtes (quinze minutes pour le jeton d'accès), une rotation du refresh token à chaque usage, une révocation effective à la déconnexion et au changement de mot de passe, et une invalidation des anciennes sessions après une élévation de privilèges.

Durcir le déploiement, pas seulement le code

Beaucoup d'applications correctement codées se font prendre par leur configuration. Les en-têtes HTTP de sécurité sont l'exemple type : ils coûtent cinq minutes à poser et neutralisent des familles entières d'attaques.

# En-têtes minimales côté serveur web (nginx)
add_header Content-Security-Policy "default-src 'self'; upgrade-insecure-requests";
add_header X-Content-Type-Options "nosniff";
add_header X-Frame-Options "DENY";
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";

1. HTTPS partout grâce aux certificats gratuits et automatiques de Let's Encrypt
2. Limitation de débit sur les endpoints de connexion : cinq essais puis blocage temporaire de l'IP
3. Content-Security-Policy restrictive, testée progressivement avec le mode report-only
4. npm audit en intégration continue et mises à jour automatiques des dépendances (Dependabot)
5. Journaux des événements d'authentification, sans jamais y stocker de secret
6. Sauvegardes testées régulièrement : la règle 3-2-1 (trois copies, deux supports, une hors site)

Une habitude, pas une étape

Aucune équipe ne « termine » la sécurité un vendredi soir. Elle vit dans les revues de code, les mises à jour hebdomadaires et les tests automatiques. Souvenez-vous d'Equifax : la faille était connue, le correctif existait depuis deux mois, il n'a juste jamais été déployé. L'objectif n'est donc pas l'inviolabilité, personne n'y arrive ; c'est qu'attaquer votre site coûte plus cher que ce qu'il rapporte. C'est un calcul économique, et chaque règle de cet article décale le curseur en votre faveur.

On ne construit pas un coffre-fort imprenable. On construit un système dont le cambriolage ne vaut pas l'effort.

Sources et pour aller plus loin

• Rapport GAO-18-559 sur la brèche Equifax de 2017
• OWASP Top 10 des risques applicatifs
• Feuille OWASP : prévention des injections SQL
• Feuille OWASP : bonnes pratiques d'authentification
• NordPass : classement annuel des mots de passe les plus courants
• Have I Been Pwned : vérifier si vos identifiants ont fuité
• Let's Encrypt : certificats TLS gratuits et automatisés