CSRF : comprendre l’attaque et s’en protéger

Auteur : Rédaction Domeny.ForSale Publié le 19.10.2026

En bref : CSRF est une attaque dans laquelle un site tiers pousse le navigateur d’un utilisateur connecté à envoyer une requête indésirable à un autre service. Si ce service vérifie uniquement que l’utilisateur est connecté, il peut exécuter une opération sans son consentement éclairé. La protection repose sur des mesures prises dans l’application : jetons CSRF, paramètres de cookies adaptés et vérification de l’origine des requêtes.

Comment fonctionne CSRF : l’exemple de l’administration d’une boutique

CSRF signifie Cross-Site Request Forgery, c’est-à-dire falsification de requêtes intersites. L’attaque exploite le fait que le navigateur peut joindre automatiquement un cookie de session aux requêtes destinées à un service donné. Ce cookie permet au serveur de reconnaître la personne connectée sans lui redemander son mot de passe.

Imaginez que vous gérez une boutique en ligne et que son interface d’administration est ouverte. Dans un autre onglet, vous consultez une page préparée par un attaquant. Cette page tente d’envoyer à l’interface d’administration une requête visant à modifier l’adresse e-mail associée à votre compte.

Si le navigateur joint le cookie de session et que l’application ne vérifie pas aussi l’authenticité de la requête, le serveur peut considérer que cette demande vient de vous. L’attaquant n’a pas besoin de connaître votre mot de passe ni de lire le cookie : il suffit que le navigateur l’utilise lors de l’envoi de la requête.

C’est un peu comme si quelqu’un présentait un ordre à exécuter sur lequel votre tampon serait apposé automatiquement. Le système reconnaît le tampon, mais ne vérifie pas que vous souhaitez réellement effectuer cette opération précise.

Quand l’attaque peut réussir et ce qui ne l’empêche pas

Une attaque CSRF classique nécessite plusieurs conditions : l’utilisateur a une session active, le navigateur envoie automatiquement les informations d’authentification et l’application accepte une requête prévisible qui modifie l’état du compte. Il peut s’agir de modifier des données, d’ajouter un utilisateur ou de supprimer une entrée. Les conséquences dépendent des opérations disponibles et des droits de la victime.

L’attaquant n’a généralement pas besoin de lire la réponse du serveur. Le navigateur peut empêcher le site tiers de lire les données de l’interface d’administration, tout en permettant l’envoi de certaines requêtes. C’est pourquoi la politique de même origine, qui limite l’accès des scripts aux ressources d’autres origines, ne remplace pas une protection contre CSRF.

HTTPS ne résout pas non plus ce problème. Il chiffre la connexion et protège les données en transit, mais ne confirme pas que l’utilisateur a sciemment demandé l’opération. Utiliser la méthode POST plutôt que GET ne suffit pas non plus : un site tiers peut envoyer un simple formulaire POST.

CSRF et XSS sont deux attaques différentes. XSS consiste à exécuter du code indésirable dans le contexte d’un site de confiance, tandis que CSRF exploite la confiance que le service accorde aux requêtes provenant du navigateur de l’utilisateur. Une faille XSS peut toutefois compromettre les protections contre CSRF, par exemple en permettant de lire le jeton.

Comment protéger une application contre CSRF

Le point de départ le plus sûr est la protection intégrée au framework utilisé. Il faut l’activer et vérifier qu’elle couvre toutes les opérations modifiant les données, et pas seulement le formulaire de connexion.

Vérifiez le jeton CSRF. Il s’agit d’une valeur imprévisible que l’application insère dans un formulaire ou fournit pour qu’elle soit envoyée dans un en-tête approprié. Le serveur la vérifie avant d’exécuter l’opération. Dans une approche courante, le jeton est lié à la session ; un site tiers ne doit pouvoir ni le lire ni le deviner. Le jeton ne doit pas figurer dans l’adresse URL.
Définissez l’attribut SameSite du cookie de session. Il limite l’envoi du cookie dans les contextes intersites. Les valeurs Lax et Strict imposent des restrictions différentes : il faut donc tester le réglage choisi avec la connexion et les intégrations. SameSite constitue une couche de protection, pas un substitut au jeton valable dans tous les cas.
Vérifiez l’origine de la requête. L’en-tête Origin, ainsi que Referer dans un mécanisme conçu à cet effet, aide à déterminer d’où provient la requête. Comparez sa valeur à une liste d’adresses autorisées définies avec précision, plutôt que de rechercher simplement un fragment du nom de domaine.
Ne modifiez pas les données avec GET. Ouvrir un lien ne doit pas supprimer un compte ni valider une commande. Les opérations modifiant les données doivent utiliser les méthodes appropriées et rester soumises aux vérifications CSRF.

Pour les actions particulièrement sensibles, ajoutez une nouvelle authentification ou une confirmation distincte. Les cookies de session doivent également avoir les attributs Secure et HttpOnly appropriés, même si aucun des deux ne suffit à empêcher CSRF.

Une API a-t-elle aussi besoin de protection ?

Une API, c’est-à-dire une interface permettant à des programmes de communiquer entre eux, peut également être vulnérable à CSRF si elle utilise une session authentifiée par cookie. Le simple fait de répondre au format JSON ne garantit pas la sécurité.

Lorsque le client ajoute explicitement un jeton d’accès dans l’en-tête Authorization et que le navigateur ne le joint pas automatiquement, le mécanisme classique de CSRF ne s’applique généralement pas. Cela ne protège toutefois ni contre le vol du jeton ni contre XSS. CORS, le mécanisme qui régit l’accès entre origines différentes, ne constitue pas non plus à lui seul une protection contre CSRF.

Que vérifier sur votre propre site ?

Commencez par une opération, par exemple la modification de l’adresse e-mail. Avec un compte de test, dans votre propre environnement ou avec l’autorisation du propriétaire, vérifiez qu’une requête sans jeton CSRF ou avec un jeton incorrect est rejetée et ne modifie effectivement aucune donnée. Contrôlez ensuite les paramètres du cookie ainsi que les autres chemins permettant d’exécuter la même opération.

Si vous utilisez un système prêt à l’emploi, vérifiez le fonctionnement de sa protection dans la documentation officielle de la version utilisée et des extensions installées. En tant qu’utilisateur, vous ne pouvez pas remédier à l’absence de protections sur le serveur ; vous pouvez limiter les risques en vous déconnectant après avoir utilisé une interface sensible. En tant que propriétaire de l’application, commencez par examiner les opérations qui modifient les données : ce sont elles pour lesquelles il faut vérifier que la requête provient bien d’une interface autorisée.

À lire aussi : Que signifie www ?