Réponse courte : Sécurisez tout le cycle de la requête : borner et parser l'entrée, authentifier, autoriser l'action et l'objet, utiliser des API de données sûres, contraindre les appels sortants et maîtriser erreurs et logs.
1. Borner la requête avant de la parser
Fixez des limites de headers, taille de corps, profondeur JSON, upload et durée au reverse proxy et dans l'application. Refusez types de contenu inattendus et paramètres ambigus. Les schémas des opérations sensibles doivent rejeter les champs inconnus pour éviter la mass assignment.
2. Centraliser l'identité, distribuer l'autorisation
Authentifiez avec un middleware éprouvé, mais autorisez chaque opération. Un token correctement signé peut être expiré, destiné à une autre audience ou sans permission suffisante. Ne faites pas confiance à un identifiant tenant envoyé dans le corps si la session le définit déjà.
app.get("/api/invoices/:id", requireSession, async (req, res) => {
const invoice = await db.query(
"SELECT id,total FROM invoices WHERE id = $1 AND workspace_id = $2",
[req.params.id, req.session.workspaceId]
);
if (!invoice.rowCount) return res.sendStatus(404);
res.json(invoice.rows[0]);
});3. Protéger interpréteurs, fichiers et requêtes sortantes
Paramétrez les requêtes de base ; ne construisez jamais de commande depuis une chaîne utilisateur. Générez le nom des uploads, stockez hors de la racine web et vérifiez leur interprétation en aval. Pour les URL, autorisez schémas et hôtes nécessaires, contrôlez les adresses résolues, limitez les redirections et bloquez les destinations internes au niveau réseau.
4. Échouer et opérer en sécurité
Retournez des erreurs stables sans stack trace ni détail de base. Journalisez corrélation, événement et acteur, jamais tokens ni corps sensibles. Limitez le débit par identité pertinente et protégez séparément connexion, récupération et endpoints coûteux. Maintenez Node.js et les dépendances supportés, verrouillez les versions et examinez les scripts d'installation.
Le Permission Model Node.js réduit les accès accidentels mais sa documentation ne le présente pas comme une sandbox face à du code malveillant. C'est une défense complémentaire.
Erreurs fréquentes
- Faire confiance aux claims JWT décodés sans vérifier algorithme, issuer et audience.
- Autoriser la route mais pas la ligne de base visée.
- Laisser les valeurs par défaut Express définir les limites de production.
- Valider l'URL initiale mais suivre une redirection vers un réseau privé.
- Retourner les exceptions brutes ou journaliser Authorization.
- Confondre Permission Model avec une isolation de processus.
Checklist
- Proxy et application imposent tailles et délais explicites.
- Les schémas rejettent types, bornes et champs sensibles inattendus.
- Les tokens vérifient signature, issuer, audience, expiration et usage.
- Chaque requête objet est scopée au principal ou tenant authentifié.
- SQL paramétré ; commandes et templates n'intègrent pas les entrées.
- Les appels sortants ont des restrictions applicatives et réseau.
- Erreurs et logs excluent secrets et détails d'implémentation.
- Runtime et dépendances suivent une politique de mise à jour.
Limites
La revue du code API ne couvre ni reverse proxy, IAM cloud, permissions de base ou egress de production si ces configurations ne sont pas incluses. Charge, concurrence et race conditions exigent aussi des tests d'exécution. Modélisez le système déployé, pas seulement Express ou Fastify.
Sources primaires
Ressources liées
Faire relire une API Node.js
Appliquer ces contrôles au code et aux frontières produit réelles.