C'est LA règle de sécurité la plus fondamentale concernant les mots de passe, et la comprendre (avec le fonctionnement de bcrypt) est essentiel — car une erreur ici expose les mots de passe de TOUS vos utilisateurs, avec des conséquences graves. Pourquoi ne JAMAIS stocker en clair : imaginez que vous stockez les mots de passe tels quels dans votre base (password: "monMotDePasse123"). Si votre base est un jour COMPROMISE (piratage, fuite, employé malveillant, sauvegarde volée — cela arrive RÉGULIÈREMENT, l'actualité en témoigne), TOUS les mots de passe sont immédiatement exposés en clair. Conséquences dramatiques : (1) l'attaquant peut se connecter à tous les comptes de votre application ; (2) PIRE — beaucoup d'utilisateurs RÉUTILISENT le même mot de passe ailleurs (email, banque, autres services), donc l'attaquant peut compromettre leurs autres comptes (« credential stuffing »). Votre fuite met en danger les utilisateurs bien au-delà de votre application. C'est une catastrophe éthique et légale (responsabilité, sanctions RGPD…). Stocker en clair est une faute grave et inexcusable. La solution : le HACHAGE. Au lieu du mot de passe, on stocke son HACHAGE — le résultat d'une fonction à SENS UNIQUE : facile à calculer dans un sens (mot de passe → hachage), impossible à inverser (hachage → mot de passe). On ne peut pas « retrouver » le mot de passe depuis le hachage. Comment ça marche en pratique : (1) À l'INSCRIPTION : on hache le mot de passe fourni et on stocke LE HACHAGE (jamais le mot de passe). (2) À la CONNEXION : on hache le mot de passe fourni et on COMPARE au hachage stocké — s'ils correspondent, le mot de passe est bon (on n'a jamais eu besoin de « déchiffrer » quoi que ce soit). Résultat : si la base est volée, l'attaquant n'a que des HACHAGES, pas les mots de passe — il ne peut pas se connecter directement. Pourquoi BCRYPT spécifiquement (et pas un simple hachage) : un hachage naïf (comme MD5 ou SHA rapide) ne suffit PAS, pour deux raisons que bcrypt résout : (1) Le SEL (salt). Sans sel, deux utilisateurs avec le même mot de passe auraient le même hachage, et des attaquants utilisent des « tables arc-en-ciel » (tables précalculées de hachages de mots de passe courants) pour retrouver les mots de passe. bcrypt ajoute un SEL aléatoire UNIQUE à chaque mot de passe avant de le hacher — ainsi, même deux mots de passe identiques ont des hachages différents, et les tables précalculées deviennent inutiles (il faudrait une table par sel). Le sel est stocké avec le hachage (c'est prévu, il n'a pas à être secret). (2) La LENTEUR VOLONTAIRE (facteur de coût). Un hachage rapide (MD5, SHA) permet à un attaquant de tester des MILLIARDS de mots de passe par seconde (force brute) si votre base fuite. bcrypt est VOLONTAIREMENT LENT (et son coût est réglable) — hacher prend un temps notable (des dizaines/centaines de millisecondes). Pour votre application, c'est négligeable (on ne hache qu'à l'inscription/connexion). Mais pour un attaquant qui veut tester des milliards de possibilités, cette lenteur rend la force brute BEAUCOUP plus coûteuse et lente — une protection majeure. De plus, le facteur de coût est AJUSTABLE : on peut l'augmenter à mesure que les ordinateurs deviennent plus rapides, gardant bcrypt résistant dans le temps. Les règles à retenir : (1) JAMAIS de mot de passe en clair — toujours haché. (2) Utilisez bcrypt (ou un équivalent moderne éprouvé comme Argon2, scrypt) — PAS un simple MD5/SHA (trop rapides, cassables), PAS un hachage « maison » (vous feriez des erreurs). Les bibliothèques éprouvées gèrent le sel et la lenteur correctement. (3) Ne « déchiffrez » jamais un mot de passe (c'est à sens unique — d'où le fait qu'une application sérieuse ne peut pas vous RENVOYER votre mot de passe oublié, seulement vous permettre de le RÉINITIALISER — un signe de bonne sécurité). Points liés : (1) encouragez des mots de passe FORTS (longueur, complexité) et envisagez l'authentification à deux facteurs (2FA) pour plus de sécurité. (2) La sécurité des mots de passe n'est qu'un aspect (l'authentification, l'autorisation, les failles web, HTTPS, les secrets… comptent aussi). Mais le hachage des mots de passe est un fondamental ABSOLU. En résumé : ne jamais stocker en clair (une fuite exposerait tous les mots de passe, mettant en danger vos utilisateurs partout) ; stocker le HACHAGE via bcrypt, qui protège par le SEL (contre les tables précalculées) et la LENTEUR volontaire ajustable (contre la force brute). C'est un savoir de sécurité non négociable pour tout développeur qui gère des comptes — une responsabilité envers de vraies personnes dont vous protégez les données. Une application qui stocke les mots de passe en clair est une faute professionnelle grave ; utiliser bcrypt correctement est le minimum vital.

La sécurité EST vaste, et c'est normal de se sentir dépassé — mais on peut l'aborder progressivement en commençant par les fondamentaux à fort impact, et surtout en adoptant le bon ÉTAT D'ESPRIT, qui est plus important que de connaître toutes les failles. L'état d'esprit fondamental : « ne jamais faire confiance aux entrées ni au client ». C'est LE principe qui sous-tend la sécurité web. Tout ce qui vient de l'EXTÉRIEUR (données de formulaires, paramètres d'URL, en-têtes, corps de requêtes, fichiers uploadés, et même les requêtes venant de « votre » front — car un attaquant peut envoyer des requêtes directement, sans passer par votre interface) est POTENTIELLEMENT MALVEILLANT. Vous devez traiter toute entrée comme suspecte : la valider, l'assainir, la manipuler avec prudence (requêtes paramétrées, échappement, contrôles). Cet état d'esprit défensif — supposer le pire des entrées — vous fait éviter une grande partie des failles, même celles que vous ne connaissez pas nommément. Par où COMMENCER (les fondamentaux à fort impact) : (1) Mots de passe : bcrypt. Ne jamais stocker en clair, toujours hacher avec bcrypt. Fondamental et à fort impact (une fuite exposerait tout). (2) Ne jamais faire confiance aux entrées : validez les données (section 4-4), utilisez des requêtes paramétrées/ORM (contre l'injection SQL, section 3-4), assainissez ce qui sera affiché (contre le XSS). (3) Protéger les SECRETS : les clés, mots de passe de base, secrets JWT ne doivent JAMAIS être dans le code ni dans Git — utilisez des variables d'environnement (.env, ignoré par Git). Une fuite de secret (une clé dans un dépôt public) est une faille classique et grave. (4) HTTPS : chiffrer les communications (indispensable en production — sinon mots de passe et données circulent en clair). (5) Authentification et autorisation correctes : vérifier QUI (authentification) ET vérifier le DROIT (autorisation) — ne pas confondre, ne pas oublier l'autorisation (un utilisateur authentifié ne doit pas pouvoir accéder aux données d'un AUTRE utilisateur — une faille fréquente et grave). (6) Helmet : un middleware qui définit des en-têtes HTTP de sécurité (facile à ajouter, gain immédiat). (7) Garder les dépendances à jour (npm audit, section 1-4) : les failles de dépendances sont un vecteur réel. (8) Rate limiting : limiter les requêtes (contre la force brute, les abus). Avec ces fondamentaux, vous couvrez déjà une grande partie des risques courants. Comment PROGRESSER (sans se noyer) : (1) Commencez par les fondamentaux ci-dessus — ils ont le meilleur rapport impact/effort. Ne cherchez pas à tout maîtriser d'un coup. (2) Apprenez les failles COURANTES progressivement : l'injection (SQL/NoSQL), le XSS (cross-site scripting — injection de scripts), le CSRF (cross-site request forgery), les problèmes d'authentification/autorisation, l'exposition de données sensibles. Des ressources comme l'« OWASP Top 10 » (la liste des principales failles web) sont d'excellents guides d'apprentissage structurés. (3) Utilisez des outils et bibliothèques éprouvés : bcrypt pour les mots de passe, des bibliothèques d'auth (Passport), de validation (Zod/Joi), Helmet — ne réinventez pas la sécurité, appuyez-vous sur ce qui est testé par la communauté. (4) Restez informé : la sécurité évolue (nouvelles failles, nouvelles pratiques). (5) Testez et faites relire : les revues de code et, sur les projets sérieux, les audits de sécurité aident. L'état d'esprit global : (1) la sécurité est une PRÉOCCUPATION PERMANENTE, pas une fonctionnalité à ajouter à la fin. Pensez sécurité DÈS la conception (« comment cette entrée pourrait-elle être abusée ? », « qui a le droit d'accéder à ça ? »). (2) Adoptez la posture DÉFENSIVE (ne pas faire confiance aux entrées, supposer le pire). (3) Acceptez de ne pas tout savoir — commencez par les fondamentaux, apprenez progressivement, utilisez des outils éprouvés. (4) Prenez la RESPONSABILITÉ au sérieux : vous manipulez les données et comptes de vraies personnes ; une faille peut leur nuire réellement. La sécurité est une obligation éthique et professionnelle. En résumé : ne soyez pas paralysé par l'ampleur de la sécurité — commencez par les fondamentaux à fort impact (bcrypt, ne pas faire confiance aux entrées, protéger les secrets, HTTPS, auth/autorisation correctes, Helmet, dépendances à jour), adoptez l'état d'esprit défensif (« ne jamais faire confiance aux entrées »), appuyez-vous sur des outils éprouvés, et apprenez progressivement les failles courantes (OWASP Top 10). L'état d'esprit (méfiance envers les entrées, sécurité dès la conception, responsabilité) compte plus que de connaître toutes les failles par cœur. Un développeur qui INTÈGRE ces réflexes de base et cette posture défensive évite déjà l'immense majorité des problèmes — bien plus qu'un développeur qui connaît des failles obscures mais néglige les fondamentaux. La sécurité est un pilier du métier de développeur back-end : prenez-la au sérieux dès le début, progressivement mais résolument.