Sécurité des API Node.js : notre checklist

Chaque API Express qui sort de notre atelier passe la même revue de sécurité avant de toucher la production. La checklist est assez courte pour être réellement suivie, et c'est tout l'intérêt — un document de sécurité de quarante points que personne ne lit ne protège rien.

Premièrement, les frontières d'authentification. Les jetons sont vérifiés sur chaque route protégée via un middleware, jamais à l'intérieur des handlers individuels où un refactoring peut silencieusement supprimer le contrôle. Les JWT ont des expirations courtes, et toute opération privilégiée relit le rôle de l'utilisateur depuis la base de données plutôt que de faire confiance aux claims figés dans un jeton qui peut dater d'un jour.

Deuxièmement, le rate limiting sur chaque surface publique — avec des limites différentes selon les surfaces. Les points de connexion reçoivent une poignée de tentatives par fenêtre, car le credential stuffing est une affaire de volume. Les formulaires publics reçoivent juste assez de marge pour les vrais utilisateurs et pas plus. Le limiteur est un middleware ennuyeux, et l'ennuyeux est exactement ce que vous voulez face à une attaque par force brute.

Troisièmement, des requêtes paramétrées sans exception. Chaque instruction SQL de notre base de code utilise des placeholders ; l'interpolation de chaînes dans une requête est un rejet automatique en revue, même quand la valeur « ne peut absolument pas » venir d'un utilisateur. Les valeurs qui doivent réellement modifier la structure d'une requête — une colonne de tri, un intervalle — proviennent d'une liste blanche codée en dur, jamais de la requête HTTP.

Quatrièmement, valider à la frontière et échapper à la sortie. Les corps de requête sont vérifiés en forme et en cohérence dès leur arrivée. Tout ce qui part ensuite dans un e-mail, une ligne de log ou un template HTML est échappé pour cette destination. Le cross-site scripting est presque toujours un problème de sortie déguisé en problème d'entrée.

Enfin, les essentiels discrets : en-têtes de sécurité via Helmet, CORS verrouillé sur des origines connues, secrets dans des variables d'environnement qui n'atteignent jamais le dépôt, et des réponses d'erreur qui disent « quelque chose s'est mal passé » au client pendant que la vraie stack trace part dans les logs. Les attaquants lisent les messages d'erreur plus attentivement que la plupart des développeurs.

Rien de tout cela n'est exotique. C'est la leçon que nous offririons à n'importe quelle équipe : les API qui se font compromettre manquent rarement de défenses avancées — elles manquent des bases, appliquées avec constance. Une checklist que vous exécutez vraiment vaut mieux qu'un diagramme d'architecture que vous admirez.