CSRF Protection for Stateless REST APIs

1. Qu'est-ce qu'une attaque CSRF ?

Avant de plonger dans la configuration, assurons-nous de bien comprendre la menace. Une attaque CSRF (ou "falsification de requête inter-sites") consiste à tromper un utilisateur authentifié pour qu'il exécute à son insu une action sur une application web. L'attaquant exploite le fait que le navigateur de la victime envoie automatiquement les cookies d'authentification avec chaque requête vers le site concerné.

Pour une explication claire et un exemple pratique en français, je vous propose de visionner le début de la vidéo suivante.

En résumé, l'attaque fonctionne parce que :

1. L'utilisateur est authentifié sur le site cible (ex: ma-banque.com), et son navigateur a stocké un cookie de session.
2. L'utilisateur visite un site malveillant (site-malveillant.com).
3. Ce site contient un formulaire ou un script qui envoie une requête vers ma-banque.com (ex: pour effectuer un virement).
4. Le navigateur, voyant une requête vers ma-banque.com, y joint automatiquement le cookie de session.
5. Pour ma-banque.com, la requête semble légitime car elle vient avec un cookie de session valide. L'action est exécutée.

2. Le dilemme : JWT, XSS et CSRF

Dans notre architecture stateless avec JWT, nous n'utilisons pas de cookie de session. Le token est envoyé dans l'en-tête Authorization. Dans ce cas, nous sommes naturellement protégés du CSRF, car un site tiers ne peut pas forcer le navigateur à ajouter cet en-tête. C'est pourquoi de nombreux tutoriels conseillent de simplement désactiver la protection CSRF de Spring Security :

// Extrait d'une configuration de sécurité typique pour une API JWT
@Bean
public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
    return http
        .csrf(AbstractHttpConfigurer::disable) // <- La ligne souvent recommandée
        // ... reste de la configuration
        .build();
}

Vous trouverez cette approche dans l'article de sfeir.dev (resource_id: [LINK](https://www.sfeir.dev/back/securisez-vos-api-avec-spring-security-jwt/)) que nous avons consulté pour la configuration JWT.

Alors, où est le problème ?

Le problème réside dans le stockage du JWT côté client. Comme nous l'avons évoqué, si vous stockez le JWT dans le localStorage du navigateur (une pratique courante), il est vulnérable aux attaques XSS (Cross-Site Scripting). Un script malveillant injecté sur votre site pourrait lire le token depuis le localStorage et le voler.

Pour se prémunir du XSS, la meilleure pratique est de stocker le JWT dans un cookie HttpOnly. Ce type de cookie ne peut pas être lu par JavaScript, ce qui neutralise le vol de token via XSS. Mais en faisant cela... nous rendons notre application de nouveau vulnérable au CSRF, car les cookies HttpOnly sont, eux aussi, envoyés automatiquement par le navigateur !

C'est le dilemme :

• localStorage : Vulnérable au XSS.
• Cookie HttpOnly : Vulnérable au CSRF.

L'article suivant, en français, explique ce dilemme et introduit la solution que nous allons adopter.

3. La solution : Le "Double Submit Cookie Pattern"

La solution à ce dilemme est une technique appelée Double Submit Cookie. Elle est parfaitement adaptée à nos API stateless et Spring Security la supporte nativement.

Le principe est le suivant :

1. En plus du cookie HttpOnly contenant le JWT, le serveur génère un second cookie contenant un token CSRF. Ce cookie-là n'est pas HttpOnly, il doit être lisible par le code JavaScript du frontend.
2. Pour chaque requête qui modifie l'état de l'application (POST, PUT, DELETE, PATCH), le client (votre application React) doit :
   • Lire la valeur du token CSRF depuis le cookie.
   • Ajouter cette valeur dans un en-tête HTTP (par convention, X-XSRF-TOKEN).
3. Le serveur, à la réception de la requête, vérifie deux choses :
   • La présence et la validité du cookie CSRF.
   • La présence de l'en-tête X-XSRF-TOKEN et que sa valeur correspond à celle du cookie.

Un attaquant ne peut pas contourner cette protection. Même s'il peut forcer le navigateur à envoyer le cookie CSRF, il ne peut pas lire sa valeur pour la copier dans l'en-tête X-XSRF-TOKEN à cause de la politique de même origine (Same-Origin Policy) des navigateurs.

4. Configuration avec Spring Security

Maintenant, la pratique. Au lieu de désactiver CSRF, nous allons le configurer pour qu'il utilise cette stratégie.

La vidéo suivante, bien qu'en anglais, montre très clairement la configuration de Spring Security et l'interaction avec un client React. Le code est universel et la démonstration visuelle est très parlante.

Voici le code de configuration crucial à ajouter dans votre SecurityFilterChain :

import org.springframework.security.web.csrf.CookieCsrfTokenRepository;
import org.springframework.security.web.csrf.CsrfTokenRequestAttributeHandler;

// ...

@Bean
public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
    // Ce gestionnaire garantit que le token est chargé de manière "lazy"
    CsrfTokenRequestAttributeHandler requestHandler = new CsrfTokenRequestAttributeHandler();
    requestHandler.setCsrfRequestAttributeName(null);

    return http
            // ... configuration de sessionManagement, authorizeHttpRequests, etc.
            .csrf(csrf -> csrf
                    .csrfTokenRepository(CookieCsrfTokenRepository.withHttpOnlyFalse())
                    .csrfTokenRequestHandler(requestHandler)
            )
            // ... reste de la configuration (addFilterBefore, etc.)
            .build();
}

Points importants :

• CookieCsrfTokenRepository.withHttpOnlyFalse(): Indique à Spring de stocker le token CSRF dans un cookie (nommé XSRF-TOKEN par défaut) et de le rendre lisible par JavaScript (HttpOnly à false).
• CsrfTokenRequestAttributeHandler: Cette configuration (surtout setCsrfRequestAttributeName(null)) est une bonne pratique avec les API stateless pour éviter que Spring ne cherche le token CSRF dans les attributs de la requête serveur, optimisant légèrement le processus.
• CORS : N'oubliez pas de vous assurer que votre configuration CORS autorise l'en-tête X-XSRF-TOKEN.

Côté frontend (React), la plupart des librairies HTTP comme axios gèrent cela automatiquement. Si vous utilisez axios, il lira par défaut le cookie XSRF-TOKEN et placera sa valeur dans l'en-tête X-XSRF-TOKEN pour les requêtes cross-site.

Conclusion

Félicitations ! Vous avez terminé le module sur la sécurité. Vous êtes maintenant capable de sécuriser une API REST Spring Boot de bout en bout.

Points clés à retenir sur le CSRF :

• La protection CSRF n'est pas inutile pour une API stateless si vous stockez le JWT dans un cookie HttpOnly pour vous protéger du XSS.
• Le Double Submit Cookie Pattern est la solution standard pour ce scénario.
• Spring Security facilite grandement sa mise en place avec CookieCsrfTokenRepository.withHttpOnlyFalse().
• Cette protection nécessite une coopération entre le backend (qui fournit le token dans un cookie lisible) et le frontend (qui lit le token et le renvoie dans un en-tête).

Dans le prochain module, Architecture Logicielle et Design Patterns, nous prendrons de la hauteur. Nous commencerons par structurer notre application en couches (Présentation, Métier, Données) avec Spring, une base essentielle pour construire des applications maintenables et évolutives.