Les failles de sécurité que les développeurs Node.js déploient en production
L'année dernière, j'ai effectué une revue de code pour une startup. Le code semblait propre. Les tests passaient.
Puis j'ai vu cette ligne :
const query = \SELECT * FROM users WHERE email = '${req.body.email}'``
Il s'agit d'une faille d'injection SQL. La startup a utilisé cela en production pendant 8 mois. Aucun développeur ni aucun CTO ne l'a détectée.
Ces bugs sont invisibles car le code fonctionne. Il fonctionne jusqu'à ce qu'un utilisateur saisisse une commande malveillante dans un champ de saisie.
Arrêtez ces 5 erreurs courantes :
- SQL brut avec des entrées utilisateur N'utilisez pas de template literals pour vos requêtes. Cela permet à des attaquants d'accéder à votre base de données.
- Mauvais :
const query = \SELECT * FROM users WHERE email = '${email}'`` - Bon : Utilisez des requêtes paramétrées.
const query = 'SELECT * FROM users WHERE email = $1'db.query(query, [email])
Fuite de secrets dans Git Les développeurs committent souvent des fichiers .env dans les dépôts. Cela expose vos URL de base de données et vos clés API. Ajoutez toujours .env à votre fichier .gitignore.
Utiliser jwt.decode au lieu de jwt.verify
jwt.decodene fait que lire le jeton. Il ne vérifie pas si le jeton est authentique. N'importe qui peut forger un jeton décodé.
- Mauvais :
const user = jwt.decode(token) - Bon : Vérifiez toujours la signature.
const user = jwt.verify(token, process.env.JWT_SECRET)
- Absence de limitation de débit (rate limiting) sur les endpoints d'authentification Sans limitation de débit, les attaquants peuvent tester des millions de mots de passe par force brute. Utilisez une bibliothèque pour limiter les tentatives de connexion.
- Bon : Ajoutez une limite de 10 tentatives par tranche de 15 minutes.
- Messages d'erreur trop détaillés L'envoi de messages d'erreur bruts au client aide les attaquants à cartographier votre système. Ils voient vos noms de tables et vos types de bases de données.
- Mauvais :
res.status(500).json({ error: error.message }) - Bon : Journalisez l'erreur en interne. Envoyez un message générique à l'utilisateur.
res.status(500).json({ error: 'Something went wrong' })
Avant de déployer un endpoint, posez-vous une question : Que se passe-t-il si un utilisateur envoie des données inattendues ?
Les failles de sécurité sont rarement complexes. Elles surviennent lorsque vous oubliez de penser aux acteurs malveillants.
Quelle faille de sécurité avez-vous déjà trouvée en production ?
Source: https://dev.to/manolito99/the-security-bug-every-nodejs-developer-ships-to-production-49e6
