Protection contre les attaques CSRF dans React et les configurations d’API

La falsification de requête intersite (CSRF) est une attaque au cours de laquelle un site malveillant incite le navigateur de l’utilisateur à envoyer une requête authentifiée à votre API. Comme le navigateur joint automatiquement les cookies aux requêtes, le serveur ne peut pas distinguer une requête légitime provenant de votre application d’une requête falsifiée provenant du site de l’attaquant.

Les cookies sont à l’origine de la vulnérabilité CSRF. Lorsqu’un utilisateur est connecté à votre application, son cookie de session est stocké dans le navigateur. Lorsqu’il consulte la page de l’attaquant, celui-ci peut déclencher l’envoi d’un formulaire ou une requête de récupération vers votre API, et le navigateur inclut automatiquement le cookie de session, authentifiant ainsi la requête malveillante.

L’attribut de cookie SameSite indique aux navigateurs quand inclure les cookies dans les requêtes intersites. Il possède trois valeurs : Lax (valeur par défaut dans les navigateurs modernes : bloque les POST intersites, mais autorise les GET), Strict (bloque toutes les requêtes intersites, y compris les navigations GET) et None (autorise les requêtes intersites, mais exige l’indicateur HTTPS Secure).

SameSite=Lax bloque les requêtes intersites POST, PUT, DELETE et PATCH, c’est-à-dire les méthodes utilisées pour les mutations. Si votre API utilise GET uniquement pour les lectures et POST pour toutes les mutations, SameSite=Lax empêche efficacement le CSRF pour les SPA dans les navigateurs modernes. Il s’agit de la mesure d’atténuation de référence sur laquelle s’appuient aujourd’hui la plupart des applications.

Le modèle du double envoi de cookie est une mesure d’atténuation du CSRF dans laquelle le serveur définit un jeton CSRF aléatoire dans un cookie non-HttpOnly. Le client lit la valeur de ce cookie et l’inclut dans un en-tête de requête personnalisé (par exemple : X-CSRF-Token). Le serveur vérifie que la valeur de l’en-tête correspond à celle du cookie. Un attaquant ne peut pas lire le cookie depuis une autre origine et ne peut donc pas définir l’en-tête correct.

Le modèle du jeton synchroniseur génère un jeton CSRF unique pour chaque session utilisateur sur le serveur. Pour les formulaires HTML, le jeton est intégré dans un champ masqué. Pour les appels d’API d’une SPA, le jeton est fourni par un point d’accès ou une balise de métadonnées, puis envoyé dans un en-tête personnalisé. Le serveur valide le jeton lors de chaque requête qui modifie l’état.

Une SPA React qui stocke son JWT en mémoire ou dans localStorage et l’envoie dans un en-tête Authorization: Bearer n’est pas vulnérable au CSRF classique. Les attaques CSRF exploitent l’authentification fondée sur les cookies : la page d’un attaquant ne peut pas définir d’en-têtes personnalisés lors de requêtes interorigines en raison des restrictions CORS, et ne peut donc pas falsifier l’en-tête Authorization.

Les requêtes interorigines simples (POST de formulaire, chargement d’image) n’autorisent pas les en-têtes personnalisés. Seules les requêtes soumises à une prévalidation CORS peuvent inclure des en-têtes personnalisés, et les requêtes prévalidées exigent l’autorisation explicite du serveur. Une API qui exige un en-tête personnalisé (comme X-Requested-With: XMLHttpRequest) pour toutes les mutations est intrinsèquement protégée contre les attaques CSRF simples.

CORS contrôle quelles origines peuvent lire la réponse d’une requête interorigines. CSRF concerne les origines qui peuvent envoyer des requêtes modifiant l’état. Configurer CORS pour restreindre les origines n’empêche pas CSRF : le navigateur envoie toujours la requête et le cookie ; CORS contrôle uniquement si la réponse est visible pour JavaScript. Une attaque CSRF n’a pas besoin de lire la réponse.

Configurez les cookies de session avec : HttpOnly: true (empêche JavaScript de lire le cookie et bloque ainsi le vol de jetons fondé sur XSS), Secure: true (envoyé uniquement via HTTPS), SameSite: Lax ou Strict (empêche CSRF), ainsi qu’une valeur ou une expiration Max-Age appropriée. Ces quatre attributs renforcent considérablement la gestion des sessions.

Le routeur d’application de Next.js utilise des actions serveur, qui sont des requêtes POST. Next.js met en œuvre une protection contre CSRF en comparant l’en-tête Origin à l’hôte ; les requêtes provenant d’origines inattendues sont rejetées. Cette vérification intégrée, associée aux cookies de session SameSite=Lax, fournit une protection solide contre CSRF pour les opérations de modification fondées sur les actions serveur.

Quelle valeur de cookie SameSite bloque les requêtes POST intersites tout en autorisant les navigations GET intersites ?

CSRF exploite l’authentification fondée sur les cookies en incitant le navigateur à envoyer des requêtes intersites authentifiées. SameSite=Lax constitue la défense de base des navigateurs modernes. Les modèles du cookie à double soumission et du jeton synchronisé fournissent une protection supplémentaire. Les SPA React qui utilisent des JWT dans les en-têtes Authorization résistent intrinsèquement à CSRF. Les en-têtes obligatoires personnalisés et la vérification préalable de CORS atténuent également CSRF. Combinez toujours HttpOnly + Secure + SameSite sur les cookies de session.