Authentification sécurisée en JavaScript : comment ne pas exposer les mots de passe

Le mot de passe "qwerty123" ne fonctionne plus : pourquoi la sécurité n'est pas ennuyeuse

Imaginez : vous avez créé une super application web. Une belle interface, un code réactif, tout fonctionne à la perfection. Vous la lancez, inscrivez le premier utilisateur — et une heure plus tard, votre base de données fuit dans le domaine public. Une histoire familière ? Malheureusement, l'authentification sécurisée en JavaScript est un sujet que de nombreux développeurs remettent à plus tard. Et c'est une erreur.

Dans cet article, nous allons voir comment protéger votre application contre les attaques les plus courantes : interception de jetons, XSS, CSRF et fuite de mots de passe. Nous ne ferons pas de leçons sur « il faut bien faire » — nous montrerons du code que vous pouvez utiliser dès maintenant.

Prêts ? C'est parti.

Authentification en JavaScript : pourquoi le client est un champ de bataille

Quand on parle d'authentification sur le web, on pense souvent au backend : bases de données, sessions, hachage. Mais l'authentification JavaScript commence côté client. Et c'est là que nous attendent les pièges.

Tout ce qui fonctionne dans le navigateur peut être lu, modifié ou volé. Votre code JavaScript est un livre ouvert pour un attaquant s'il trouve une vulnérabilité. C'est pourquoi la première règle de l'authentification sécurisée est : ne faites jamais confiance au client. Jamais.

Principales menaces côté client

\n
• XSS (Cross-Site Scripting) — un attaquant injecte un script qui vole les jetons depuis le localStorage.
\n
• CSRF (Cross-Site Request Forgery) — l'utilisateur est authentifié, et un site malveillant envoie des requêtes en son nom.
\n
• Man-in-the-Middle — interception du trafic si HTTPS n'est pas utilisé.
\n
• Fuite de mots de passe — envoi du mot de passe en clair ou stockage dans le code.
\n

Ça fait peur ? En réalité, se protéger contre cela n'est pas si compliqué. L'essentiel est de savoir quels outils utiliser.

JWT : pratique, mais avec un piège

JWT (JSON Web Token) est un standard pour créer des jetons d'accès. Il est léger, ne nécessite pas de stockage côté serveur et convient parfaitement aux SPA. Mais sa popularité en fait une cible.

De nombreux développeurs stockent les JWT dans localStorage. C'est une erreur. localStorage est accessible depuis n'importe quel code JavaScript sur la page. Si vous avez ne serait-ce qu'une vulnérabilité XSS — le jeton est volé.

Comment stocker correctement les JWT

La meilleure méthode est le cookie httpOnly. Les cookies avec le flag httpOnly sont inaccessibles depuis JavaScript. XSS ne pourra pas les voler. Mais il y a un inconvénient : les cookies sont automatiquement envoyés avec chaque requête, ce qui rend l'application vulnérable aux CSRF. La solution — utiliser SameSite et des jetons CSRF.

Voici un exemple de configuration d'un cookie httpOnly côté backend (Node.js avec Express) :

// Serveur (Node.js / Express)\nres.cookie('token', jwtToken, {\n  httpOnly: true,       // Inaccessible depuis JavaScript\n  secure: true,         // Uniquement via HTTPS\n  sameSite: 'strict',   // Protection contre CSRF\n  maxAge: 3600000       // 1 heure\n});

Côté client, vous envoyez simplement les requêtes — les cookies seront joints automatiquement :

// Client (JavaScript)\nfetch('/api/profile', {\n  method: 'GET',\n  credentials: 'include' // Obligatoire !\n})\n.then(res => res.json())\n.then(data => console.log(data));

Notez : credentials: 'include' — sans cela, les cookies ne seront pas envoyés vers une autre origine.

Hachage des mots de passe : bcrypt à la rescousse

Stocker les mots de passe en clair, c'est comme laisser les clés de la maison sous le paillasson. Même si votre site est piraté, les mots de passe doivent être inutiles pour l'attaquant.

bcrypt est un algorithme de hachage spécialement conçu pour être lent. Parce que hacher un mot de passe pour un utilisateur prend une fraction de seconde, mais pour le casser — des années. En JavaScript (Node.js), utilisez la bibliothèque b