Bonnes pratiques de sécurité pour les développeurs web
La sécurité web n’est pas optionnelle. Face à l’augmentation des cybermenaces, les développeurs doivent intégrer la sécurité à chaque couche de leurs applications. Ce guide couvre les pratiques essentielles que vous devriez mettre en place dès aujourd’hui.
Sécurité des mots de passe
Ne jamais stocker les mots de passe en clair
Hachez toujours les mots de passe avec des algorithmes modernes comme bcrypt, Argon2 ou scrypt. Ces algorithmes sont conçus pour être lents, rendant les attaques par force brute impraticables.
// Recommandé : Utiliser bcrypt
const bcrypt = require('bcrypt');
const hash = await bcrypt.hash(password, 12);Comparaison des algorithmes de hachage
Tous les algorithmes de hachage ne se valent pas. Le choix dépend de votre modèle de menace et de votre cas d’utilisation :
| Algorithme | Taille de sortie | Vitesse | Cas d’utilisation | Statut de sécurité |
|---|---|---|---|---|
| MD5 | 128 bits | Très rapide | Sommes de contrôle, hachage non-sécurité | Compromis pour la sécurité |
| SHA-256 | 256 bits | Rapide | Intégrité des données, signatures numériques | Sécurisé |
| bcrypt | 184 bits | Lent (ajustable) | Hachage de mots de passe | Sécurisé |
| Argon2 | Configurable | Lent (ajustable) | Hachage de mots de passe (moderne) | Recommandé pour les nouveaux projets |
bcrypt et Argon2 sont délibérément lents — c’est une fonctionnalité, pas un défaut. Chaque opération de hachage prend des dizaines ou centaines de millisecondes, rendant les attaques par force brute à grande échelle économiquement irréalisables.
Comprendre l’entropie des mots de passe
La force d’un mot de passe peut être mesurée mathématiquement avec l’entropie : entropy = log2(charset_size^length). Un mot de passe de 8 caractères en minuscules (26 caractères) a environ 37,6 bits d’entropie. Un mot de passe de 16 caractères mélangeant majuscules, minuscules, chiffres et symboles (95 caractères) a environ 105 bits — exponentiellement plus difficile à craquer. C’est pourquoi la longueur compte plus que la complexité pour la plupart des utilisateurs. Pour approfondir les mathématiques derrière la solidité des mots de passe, consultez notre guide sur l’entropie des mots de passe.
Utiliser un gestionnaire de mots de passe
Recommandez à vos utilisateurs d’adopter un gestionnaire de mots de passe. Les mots de passe choisis par les humains suivent des schémas prévisibles que les attaquants exploitent avec des attaques par dictionnaire. Les gestionnaires de mots de passe génèrent des chaînes véritablement aléatoires et éliminent la réutilisation des mots de passe entre les services — l’un des vecteurs les plus courants pour les attaques de bourrage d’identifiants.
Utiliser suffisamment de tours de salage
Les tours de salage déterminent le coût computationnel. Plus c’est élevé, plus c’est sécurisé mais plus lent. 10 à 12 tours constituent un bon équilibre pour la plupart des applications.
Validation des entrées
Valider côté client et côté serveur
La validation côté client améliore l’expérience utilisateur, mais la validation côté serveur est essentielle pour la sécurité. Ne faites jamais confiance aux entrées du client.
Assainir toutes les entrées utilisateur
Prévenez les attaques par injection en assainissant les entrées :
- Utilisez des requêtes paramétrées pour le SQL
- Échappez les sorties HTML pour prévenir le XSS
- Validez strictement les téléchargements de fichiers
Exemples concrets d’attaques
Comprendre les attaques réelles aide à mieux s’en défendre. Considérez un formulaire de commentaires qui affiche directement les entrées utilisateur en HTML. Un attaquant soumet :
<script>alert('xss')</script>Si l’application affiche ce contenu sans l’échapper, le script s’exécute dans le navigateur de chaque visiteur — volant des cookies, redirigeant les utilisateurs ou injectant des enregistreurs de frappe. La solution : toujours encoder les sorties selon le contexte. Utilisez des bibliothèques comme DOMPurify pour l’assainissement HTML.
L’injection SQL est tout aussi dangereuse. Dans un formulaire de connexion, un attaquant saisit comme nom d’utilisateur :
' OR 1=1 --Si la requête est construite par concaténation de chaînes ("SELECT * FROM users WHERE username='" + input + "'"), cela contourne entièrement l’authentification. Le -- met en commentaire le reste de la requête. La solution : toujours utiliser des requêtes paramétrées (aussi appelées instructions préparées). Toutes les bibliothèques de bases de données majeures les prennent en charge :
// INCORRECT : Concaténation de chaînes
db.query(`SELECT * FROM users WHERE username='${input}'`);
// CORRECT : Requête paramétrée
db.query('SELECT * FROM users WHERE username = $1', [input]);Politique de sécurité du contenu (CSP)
En tant que défense en profondeur, déployez les en-têtes Content Security Policy. Le CSP indique au navigateur quelles sources de contenu sont fiables, bloquant efficacement les scripts inline et le chargement de ressources non autorisées. Même si une vulnérabilité XSS existe dans votre code, un CSP strict peut empêcher l’exécution du script injecté. Commencez avec Content-Security-Policy: default-src 'self' et ajoutez progressivement des exceptions selon les besoins.
Fonctions de hachage
Choisir le bon algorithme de hachage
Différents cas d’utilisation nécessitent différentes fonctions de hachage :
| Cas d’utilisation | Recommandé |
|---|---|
| Mots de passe | bcrypt, Argon2 |
| Intégrité | SHA-256 |
| Sommes de contrôle | SHA-256, MD5 (non-sécurité) |
| Hachage rapide | BLAKE3 |
Comprendre la sortie de hachage et les collisions
MD5 produit un hachage de 128 bits (32 caractères hexadécimaux), tandis que SHA-256 produit un hachage de 256 bits (64 caractères hexadécimaux). Cette différence est importante : un espace de sortie plus grand signifie exponentiellement plus de valeurs de hachage possibles, rendant les collisions bien moins probables. Une collision se produit lorsque deux entrées différentes produisent le même hachage — un attaquant capable de fabriquer des collisions peut forger des signatures numériques ou altérer des données vérifiées.
Les collisions MD5 peuvent être générées en quelques secondes sur du matériel moderne. SHA-256 reste résistant aux collisions sans attaque pratique connue. C’est pourquoi choisir le bon algorithme pour le bon contexte est critique :
- Sommes de contrôle et déduplication : MD5 est acceptable quand la sécurité n’est pas en jeu
- Intégrité des données et signatures : SHA-256 offre une forte résistance aux collisions
- Stockage des mots de passe : bcrypt ou Argon2, qui ajoutent du sel et une lenteur délibérée
HMAC pour l’authentification des messages
Lorsque vous devez vérifier à la fois l’intégrité et l’authenticité d’un message, utilisez HMAC (Hash-based Message Authentication Code). HMAC combine une fonction de hachage avec une clé secrète, garantissant que seules les parties connaissant la clé peuvent générer ou vérifier le tag. C’est essentiel pour l’authentification d’API, la vérification de webhooks et la génération de jetons sécurisés.
Ne jamais utiliser MD5 ou SHA-1 pour la sécurité
MD5 et SHA-1 sont compromis à des fins de sécurité. Utilisez SHA-256 ou SHA-3 pour le hachage cryptographique.
HTTPS partout
Ce que TLS fait réellement
TLS (Transport Layer Security) fournit trois protections essentielles : le chiffrement en transit (empêchant l’écoute clandestine), l’authentification du serveur (prouvant que vous communiquez avec le vrai serveur, pas un imposteur) et l’intégrité des données (détectant toute altération pendant la transmission). Sans TLS, toutes les données entre vos utilisateurs et votre serveur — mots de passe, jetons, informations personnelles — circulent en clair.
Toujours utiliser TLS
- Obtenez des certificats auprès d’autorités de certification de confiance (Let’s Encrypt est gratuit et entièrement automatisé)
- Redirigez HTTP vers HTTPS
- Utilisez les en-têtes HSTS
- Maintenez les versions TLS à jour
HSTS et contenu mixte
Les en-têtes HTTP Strict Transport Security (HSTS) indiquent aux navigateurs de se connecter uniquement via HTTPS, même si l’utilisateur tape http://. Configurez Strict-Transport-Security: max-age=31536000; includeSubDomains pour l’appliquer pendant un an sur tous les sous-domaines. Cela empêche les attaques de type SSL stripping où un attaquant dégrade la connexion en HTTP.
Attention aux avertissements de contenu mixte : si votre page HTTPS charge des images, scripts ou feuilles de style via HTTP, les navigateurs les bloqueront ou afficheront des avertissements. Auditez vos pages pour les URL http:// codées en dur et utilisez des chemins relatifs au protocole ou imposez HTTPS pour toutes les ressources.
Authentification
Mettre en place la limitation de débit
Prévenez les attaques par force brute avec la limitation de débit :
- Limitez les tentatives de connexion par IP
- Ajoutez des délais après les tentatives échouées
- Utilisez un CAPTCHA pour les activités suspectes
Les bases de l’authentification JWT
Les JSON Web Tokens (JWT) fournissent un mécanisme d’authentification sans état structuré en header.payload.signature. Le serveur signe le jeton avec une clé secrète, et les clients l’incluent dans les requêtes suivantes. Comme le jeton contient les claims de l’utilisateur, le serveur n’a pas besoin de consulter l’état de session à chaque requête — ce qui rend les JWT bien adaptés aux systèmes distribués et aux microservices.
Définissez toujours des durées d’expiration courtes pour les jetons d’accès (par exemple 15 minutes) et utilisez des jetons de rafraîchissement pour obtenir de nouveaux jetons d’accès. Stockez les jetons de rafraîchissement de manière sécurisée (cookies httpOnly, pas dans le localStorage) et implémentez la rotation des jetons pour que chaque jeton de rafraîchissement ne puisse être utilisé qu’une seule fois.
Authentification multifacteur (MFA)
Le MFA n’est plus optionnel pour toute application sérieuse. Exiger un second facteur — codes TOTP (Google Authenticator), clés matérielles (YubiKey) ou notifications push — réduit considérablement l’impact des mots de passe compromis. Même si un attaquant obtient des identifiants valides, il ne peut pas s’authentifier sans le second facteur.
Prévention de la fixation de session
Les attaques par fixation de session se produisent lorsqu’un attaquant définit un identifiant de session connu avant que l’utilisateur ne s’authentifie. Après la connexion, l’attaquant utilise cet identifiant de session pour détourner la session authentifiée. Prévenez cela en régénérant toujours l’identifiant de session après une authentification réussie et en invalidant l’ancien.
Utiliser une gestion sécurisée des sessions
- Générez des identifiants de session cryptographiquement aléatoires
- Définissez les drapeaux secure et httpOnly sur les cookies
- Implémentez l’expiration des sessions
- Invalidez les sessions à la déconnexion
Liste de contrôle des en-têtes de sécurité
Le déploiement des bons en-têtes de réponse HTTP est l’un des moyens les plus efficaces et les moins coûteux pour renforcer votre application. Voici un tableau de référence rapide des en-têtes de sécurité essentiels :
| En-tête | Objectif | Valeur exemple |
|---|---|---|
| Content-Security-Policy | Prévenir le XSS et l’injection de données | default-src 'self' |
| Strict-Transport-Security | Forcer les connexions HTTPS | max-age=31536000; includeSubDomains |
| X-Content-Type-Options | Empêcher le MIME sniffing | nosniff |
| X-Frame-Options | Empêcher le clickjacking | DENY |
| Referrer-Policy | Contrôler les informations de référent | strict-origin-when-cross-origin |
Ces en-têtes peuvent être configurés au niveau du serveur web (Nginx, Apache), au niveau CDN/edge (Cloudflare, Vercel) ou dans votre framework applicatif. Testez vos en-têtes avec des outils comme securityheaders.com. Visez une note A+ — la plupart de ces en-têtes ne nécessitent qu’une seule ligne de configuration et ne coûtent rien à déployer.
Utiliser nos outils de sécurité
Explorez nos outils de sécurité pour vous aider dans votre développement :
- Générateur de hachage MD5 - Pour les sommes de contrôle et les systèmes hérités
- Générateur UUID - Pour des identifiants aléatoires sécurisés
- Générateur de mots de passe - Pour générer des mots de passe forts
Pour un aperçu plus large de la façon dont les outils d’encodage, de hachage et de conversion s’intègrent dans votre flux de développement, consultez notre Guide essentiel des outils de développement.
Questions fréquentes
Quelle est la vulnérabilité web la plus courante ?
Le Cross-Site Scripting (XSS) reste la vulnérabilité web la plus répandue selon l’OWASP. Elle survient lorsque les applications incluent des données non fiables dans les pages web sans validation appropriée. Prévenez le XSS en assainissant toutes les entrées utilisateur, en utilisant les en-têtes Content Security Policy et en encodant les sorties selon le contexte (HTML, JavaScript, URL ou CSS).
MD5 est-il encore sûr pour le hachage de mots de passe ?
Non — MD5 ne devrait jamais être utilisé pour le hachage de mots de passe. Sa rapidité de calcul le rend vulnérable aux attaques par force brute et aux tables arc-en-ciel. Les GPU modernes peuvent calculer des milliards de hachages MD5 par seconde. Utilisez plutôt bcrypt, scrypt ou Argon2, qui sont délibérément lents et intègrent un salage pour résister aux attaques.
Quelle longueur devrait avoir un mot de passe sécurisé en 2026 ?
Un minimum de 12 caractères est recommandé, mais 16 caractères ou plus offrent une protection nettement supérieure. La longueur compte plus que la complexité — une phrase de passe de 20 caractères comme « correct-horse-battery-staple » est plus robuste qu’un mot de passe court et complexe comme « P@ss1! ». Activez l’authentification multifacteur (MFA) pour les comptes critiques, quelle que soit la longueur du mot de passe.
Quelle est la différence entre le chiffrement et le hachage ?
Le chiffrement est réversible — vous pouvez déchiffrer les données pour retrouver leur forme originale à l’aide d’une clé. Le hachage est unidirectionnel — vous ne pouvez pas récupérer les données originales à partir d’un hachage. Utilisez le chiffrement pour les données que vous devez récupérer (comme les données utilisateur stockées), et le hachage pour celles que vous devez uniquement vérifier (comme les mots de passe et les sommes de contrôle).
Devrais-je implémenter mon propre système d’authentification ?
Non — développer un système d’authentification de zéro est risqué et source d’erreurs. Utilisez des frameworks et services éprouvés comme Auth0, Firebase Auth ou Supabase Auth. Ils gèrent le hachage des mots de passe, la gestion des sessions, la rotation des jetons, le MFA et la protection contre la force brute. Concentrez votre temps de développement sur les fonctionnalités uniques de votre application.
Conclusion
La sécurité est un processus continu, pas une tâche ponctuelle. Restez informé des dernières vulnérabilités, auditez régulièrement votre code et suivez le principe du moindre privilège. Vos utilisateurs vous confient leurs données - honorez cette confiance avec des pratiques de sécurité robustes.