flawopen.com/CSRF/Requêtes GET
Jeton CSRF pour GET : quand est-il nécessaire ?
Si GET ne fait que récupérer des données, il ne doit pas modifier l’état du serveur et n’a généralement pas besoin de jeton CSRF. Navigateurs, robots, aperçus et ressources intégrées peuvent déclencher un GET sans clic volontaire. Utilisez donc une méthode non sûre pour supprimer ou acheter, et protégez contre les CSRF les changements authentifiés par cookie. Un ancien GET qui modifie l’état reste vulnérable et nécessite une protection temporaire pendant sa migration.
Pourquoi GET doit rester une méthode sûre
La RFC 9110 définit GET comme sûre : le client ne demande pas de changement d’état. Sûr ne signifie pas absence d’effets accessoires côté serveur, comme la journalisation. GET est aussi idempotente, mais ce sont deux propriétés distinctes. Navigateurs, préchargements, robots et aperçus de liens peuvent envoyer des requêtes sûres sans action délibérée. Un <img src="..."> sur un autre site peut également faire envoyer un GET avec les cookies de l’utilisateur. Si ce point de terminaison supprime un élément ou modifie le compte, il viole la sémantique GET et un simple contenu de page peut le déclencher.
Protéger les requêtes qui modifient l’état contre les CSRF
- ✓Ne faites pas modifier l’état demandé par GET, HEAD ou OPTIONS ; utilisez POST, PUT, PATCH ou DELETE pour les mutations
- ✓Protégez les méthodes non sûres authentifiées par cookie avec la défense CSRF du framework ou un jeton validé ; ajoutez SameSite et des contrôles Origin/Fetch Metadata
- ✓Traitez tout GET modifiant l’état comme une erreur de sémantique HTTP ; ajoutez temporairement une défense CSRF, migrez l’action et retirez les secrets des URL
Questions fréquentes sur les jetons CSRF pour GET
Considérez-le comme vulnérable. Exigez temporairement une défense CSRF validée côté serveur (par exemple un jeton synchronisé avec des contrôles Origin ou Fetch Metadata lorsque disponibles), auditez caches et referers, puis migrez vers POST, PUT, PATCH ou DELETE. Évitez les jetons dans la chaîne de requête : les URL peuvent apparaître dans l’historique, les journaux et les données referer. Ce contrôle n’est qu’une transition jusqu’au respect de la sémantique des méthodes sûres.