CORS et sécurité d'une API Express : helmet, limitation de débit

CORS (Cross-Origin Resource Sharing) est le mécanisme par lequel une API indique au navigateur quels sites web ont le droit de l'appeler depuis leur code JavaScript. Sans lui, le front React servi sur une adresse ne peut pas lire les réponses d'une API servie sur une autre : le navigateur bloque, et affiche la célèbre « erreur CORS ». Ce chapitre explique cette erreur et la corrige sans tout ouvrir, puis termine la sécurisation de l'API : en-têtes de sécurité avec helmet, limitation de débit, taille des requêtes, proxy, dépendances, et une checklist reliée à l'OWASP API Security Top 10.

Pourquoi le navigateur bloque : la politique de même origine

Une origine, c'est le trio schéma + hôte + port : http://localhost:5173 et http://localhost:3000 sont deux origines différentes (le port change), comme https://frais.gsb.example et https://api.gsb.example (l'hôte change).

Par défaut, le navigateur applique la politique de même origine : le JavaScript d'une page peut envoyer des requêtes vers une autre origine, mais il ne peut pas lire la réponse, sauf si le serveur l'y autorise par des en-têtes CORS. C'est une protection de l'utilisateur : sans elle, n'importe quel site que tu visites pourrait interroger ton webmail ou l'intranet de ton entreprise avec tes cookies, et lire le résultat.

Pendant le développement d'AppliFrais, le front tourne avec Vite sur http://localhost:5173 et l'API sur http://localhost:3000. Le premier fetch du front affiche dans la console :

Access to fetch at 'http://localhost:3000/v1/fiches' from origin 'http://localhost:5173'
has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present
on the requested resource.

Trois remarques pour ne pas chercher au mauvais endroit :

• l'erreur est produite par le navigateur, pas par l'API. Les journaux de l'API montrent souvent la requête avec un code 200 : l'API a répondu, le navigateur a refusé de transmettre la réponse au JavaScript ;
• curl, Bruno, Postman, une application mobile ou un autre serveur ne sont pas concernés : la politique de même origine n'existe que dans les navigateurs ;
• pour les requêtes « non simples » (avec Authorization, avec un corps JSON, ou en PUT, PATCH, DELETE), le navigateur envoie d'abord une requête OPTIONS de pré-vérification (preflight) pour demander la permission. Le mécanisme complet est expliqué, avec un schéma, dans le cours API REST.

Le middleware cors

npm install cors

// src/app.js
import cors from 'cors';

app.use(cors({ origin: config.origineFront })); // CORS_ORIGIN=http://localhost:5173 dans le .env

Avec une seule origine, l'API envoie Access-Control-Allow-Origin: http://localhost:5173 à chaque réponse ; le navigateur de toute autre origine voit que ce n'est pas la sienne et bloque. Pour plusieurs fronts autorisés (le poste de développement et la production), passe une liste : le middleware ne renvoie l'en-tête qu'aux origines de la liste.

app.use(cors({ origin: ['http://localhost:5173', 'https://frais.gsb.example'] }));

La réponse à une pré-vérification venant d'une origine autorisée :

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: http://localhost:5173
Access-Control-Allow-Methods: GET,HEAD,PUT,PATCH,POST,DELETE
Access-Control-Allow-Headers: authorization,content-type
Vary: Origin, Access-Control-Request-Headers

app.use(cors(…)) répond lui-même aux requêtes OPTIONS de pré-vérification, pour toutes les routes. Les anciens tutoriels ajoutent app.options('*', cors()) : en Express 5, ce chemin '*' fait planter le démarrage (« Missing parameter name at index 1: * »). Supprime cette ligne, elle est inutile.

Les en-têtes de sécurité avec helmet

helmet ajoute en une ligne une série d'en-têtes HTTP qui durcissent le comportement du navigateur, et retire X-Powered-By: Express, qui annonce ta technologie aux robots qui cherchent des cibles.

npm install helmet

import helmet from 'helmet';

app.use(helmet());

Les en-têtes ajoutés par helmet 8 avec ses réglages par défaut (relevés sur l'API) :

Pour une API qui ne renvoie que du JSON, plusieurs de ces en-têtes ont peu d'effet, mais ils ne coûtent rien et protègent les pages HTML que l'API sert aussi (la documentation Swagger, une page d'erreur). Le détail de chaque en-tête et des attaques qu'il freine est dans le cours Sécurité des applications.

Limiter le débit de toute l'API

La route de connexion a déjà sa limite stricte (chapitre 9). Une limite plus large protège le reste de l'API contre un script qui l'inonde de requêtes, volontairement ou par bogue :

import { rateLimit } from 'express-rate-limit';

const limiteGenerale = rateLimit({
  windowMs: 15 * 60 * 1000, // 15 minutes
  limit: 300,               // 300 requêtes par adresse IP et par fenêtre
  standardHeaders: 'draft-8',
  legacyHeaders: false,
});

app.use('/v1', limiteGenerale);

Au-delà, l'API répond 429 Too Many Requests avec un en-tête Retry-After ; les en-têtes RateLimit et RateLimit-Policy indiquent au client sa consommation. Le compteur est gardé en mémoire : avec plusieurs instances de l'API, il faut un stockage partagé (Redis) pour que la limite soit globale.

Limiter la taille et la durée des requêtes

Chaque ressource consommée par une requête doit avoir une borne :

Le plafond de 200 caractères sur le mot de passe n'est pas un détail : sans lui, un mot de passe de plusieurs mégaoctets ferait travailler argon2 à chaque tentative.

Derrière un reverse proxy : trust proxy

En production, l'API est placée derrière Nginx (chapitre 14). Pour Node.js, toutes les requêtes viennent alors de l'adresse du proxy ; l'adresse réelle du client arrive dans l'en-tête X-Forwarded-For, ajouté par Nginx. Il faut dire à Express de faire confiance au proxy, et seulement à lui :

if (config.env === 'production') app.set('trust proxy', 1); // un seul proxy devant l'API

Avec ce réglage, req.ip donne l'adresse du client, req.protocol vaut https, et la limitation de débit compte par client au lieu de compter tout le monde comme une seule adresse. Sans proxy, ne l'active pas : n'importe quel client pourrait inventer son propre X-Forwarded-For et contourner la limite.

Les dépendances

Une API Express de taille moyenne charge plus d'une centaine de paquets. Les réflexes du chapitre 2, automatisés :

• npm audit dans la CI, qui échoue sur une vulnérabilité haute ou critique en production ;
• un outil de mise à jour automatique (Dependabot ou Renovate) qui propose une pull request quand une dépendance publie un correctif ;
• un package-lock.json versionné et npm ci partout.

Le cours Intégration continue montre comment brancher ces contrôles dans un pipeline.

Checklist : l'OWASP API Security Top 10 dans le code

L'OWASP publie la liste des dix risques les plus fréquents des API (édition 2023). Voici où chacun est traité dans l'API AppliFrais, ce qui fait aussi une excellente grille de relecture pour ta réalisation d'E6 et pour les questions de l'E7 :

Les failles applicatives qui ne sont pas propres aux API (injections, XSS, CSRF) et les tests de sécurité sont traités dans le cours Sécurité des applications.

Exercices

HTTP/1.1 200 OK
X-Powered-By: Express
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
Content-Type: application/json; charset=utf-8