À l'origine, je ne visais pas une réponse personnelle, mais après avoir lu davantage, j'ai trouvé ce que je pense être une réponse complète qui explique également pourquoi certains pourraient encore être intéressés par la protection CSRF sur les points de terminaison REST.

Pas de cookies = Pas de CSRF

C'est vraiment aussi simple que cela. Les navigateurs envoient des cookies avec toutes les demandes. Les attaques CSRF dépendent de ce comportement. Si vous n'utilisez pas de cookies et que vous ne comptez pas sur les cookies pour l'authentification, il n'y a absolument aucune place pour les attaques CSRF, et aucune raison de mettre en protection CSRF. Si vous avez des cookies, en particulier si vous les utilisez pour l'authentification, vous avez besoin d'une protection CSRF. Si tout ce que vous voulez savoir est "Ai-je besoin d'une protection CSRF pour mon point de terminaison API?" vous pouvez vous arrêter ici et repartir avec votre réponse. Sinon, le diable est dans les détails.

h / t à paj28: Bien que les cookies soient le principal vecteur d'attaque des attaques CSRF, vous êtes également vulnérable si vous utilisez HTTP / Basic authentification. Plus généralement, si le navigateur est capable de transmettre automatiquement les informations de connexion pour votre application, le CSRF est important. D'après mon expérience, les cookies sont la technologie la plus courante exploitée pour faire de la CSRF, mais il existe d'autres méthodes d'authentification qui sont utilisées qui peuvent entraîner la même vulnérabilité.

REST = Stateless

Si vous demandez à quelqu'un "qu'est-ce que REST", vous obtiendrez une variété de réponses qui traitent d'une variété de propriétés différentes. Vous pouvez le voir parce que quelqu'un a posé cette question sur le débordement de pile: https://stackoverflow.com/questions/671118/what-exactly-is-restful-programming

Une propriété de REST sur laquelle je me suis toujours appuyée est qu'il est sans état. L'application elle-même a un état bien sûr. Si vous ne pouvez pas stocker de données dans une base de données quelque part, votre application sera assez limitée. Dans ce cas cependant, l'état sans état a une signification très spécifique et importante: les applications REST ne suivent pas l'état de l'application côté client . Si vous utilisez des sessions, vous suivez (presque certainement) l'état côté client et vous n'êtes pas une application REST complète. Ainsi, une application qui utilise des sessions (en particulier pour les connexions) qui sont suivies via des cookies n'est pas une application REST-full (IMO), et est certainement vulnérable aux attaques CSRF, même si elle ressemble autrement à une application REST.

Je pense qu'il vaut la peine de noter rapidement qu'une des raisons pour lesquelles l'apatridie côté client est importante pour les applications REST est que la capacité des intermédiaires à mettre en cache les réponses est également une partie souhaitable du paradigme REST. Tant que l'application suit l'état côté client, la mise en cache n'est pas possible.

Reste ≠ Cookieless

Pour ces raisons, j'ai d'abord supposé qu'un Une application REST entièrement conforme n'aurait jamais besoin de sessions, n'a jamais besoin de cookies et n'a donc jamais besoin de sécurité CSRF. Cependant, il existe au moins un cas d'utilisation qui peut préférer les cookies de toute façon: les connexions persistantes.

Pensez à une application Web typique côté client (dans ce cas, navigateur, pas mobile). Vous commencez par vous connecter, qui utilise une API REST pour valider les informations d'identification de l'utilisateur et en retour reçoit un jeton pour autoriser les demandes futures. Pour les applications à page unique, vous pouvez simplement conserver ce jeton en mémoire, mais cela déconnectera efficacement l'utilisateur s'il ferme la page. En conséquence, il serait bon de conserver l'état quelque part qui peut durer plus longtemps qu'une seule session de navigateur. Le stockage local est une option, mais il est également vulnérable aux attaques XSS: une attaque XSS réussie peut amener l'attaquant à saisir vos jetons de connexion et à les envoyer à l'attaquant pour qu'il les utilise à sa discrétion.

Pour cela raison, j'ai vu certains suggérer d'utiliser des cookies pour stocker des jetons de connexion. Avec un cookie, vous pouvez définir l'indicateur http uniquement, qui empêche l'application de lire le cookie une fois qu'il est défini. En conséquence, en cas d'attaque XSS, l'attaquant peut toujours passer des appels en votre nom, mais il ne peut pas repartir avec le jeton d'autorisation tous ensemble. Cette utilisation de cookies ne viole pas directement l'exigence d'apatridie de REST car le serveur ne suit toujours pas l'état côté client. Il cherche simplement des informations d'authentification dans un cookie, plutôt que dans l'en-tête.

Je le mentionne car c'est potentiellement une raison légitime d'utiliser des cookies avec une API REST, même si cela dépend évidemment d'une application donnée pour équilibrer les divers problèmes de sécurité et d'utilisabilité. J'essaierais personnellement d'éviter d'utiliser des cookies avec les API REST, mais il peut très bien y avoir des raisons de les utiliser quand même. Quoi qu'il en soit, la réponse globale est simple: si vous utilisez des cookies (ou d'autres méthodes d'authentification que le navigateur peut faire automatiquement), vous avez besoin d'une protection CSRF. Si vous n'utilisez pas de cookies, vous ne le faites pas.

"il n'y a aucun moyen pour un navigateur de fournir automatiquement des informations d'authentification même s'il est en quelque sorte amené à visiter le point de terminaison de l'API"

Faites simplement attention sur les réseaux privés utilisant des authentification windows / kerberos. Dans ce scénario, le navigateur fournira automatiquement les informations d'identification (kerberos ou jeton NTLM) s'il est configuré pour le faire.

Donc - je crois que dans ce cas, CSRF est requis.

La nécessité ou non de la protection CSRF dépend de 2 facteurs: -

La requête effectue-t-elle une action de changement d'état (différente de l'API REST Statelessness) - State les actions de changement sont toute action qui changera l'état de l'application. par exemple supprimer quelque chose, ajouter quelque chose, mettre à jour quelque chose. Ce sont des actions à l'aide desquelles l'application modifiera l'état sauvegardé de l'utilisateur. Toutes les demandes de publication et quelques demandes de Get appartiendront à cette catégorie. Les API REST peuvent avoir des actions de changement d'état.

L'authentification est-elle fournie par le navigateur (non limitée aux cookies) - CSRF se produit parce que les informations d'authentification sont incluses dans la demande par le navigateur, que la demande a été lancée par l'utilisateur ou par un autre onglet ouvert. Ainsi, tout type d'authentification dans lequel le navigateur peut inclure des informations nécessite une protection CSRF. Cela inclut à la fois les sessions basées sur les cookies et l'authentification de base.

Pour toutes les demandes qui tombent dans les 2 catégories ci-dessus, une protection CSRF est nécessaire.

Une chose que j'ajouterais aux autres réponses est que la protection CSRF est nécessaire uniquement dans le domaine et le chemin du cookie en question. Ou en d'autres termes:

Autorisation! = Authentification
Cookies == Authentification
Jeton == Autorisation

Ceci est pertinent pour la mise en œuvre des connexions persistantes (votre 3e point). Si vous apposez vos cookies sur login.example.com , qui héberge votre interface utilisateur de connexion et votre point de terminaison / authorize , vous pouvez exécuter un flux OAuth implicite toutes les quelques minutes sans nécessiter une nouvelle connexion (par exemple pas de dialogue de mot de passe). Le client peut continuer et envoyer le jeton d'accès ainsi acquis à api.example.com sans CSRF, car aucun cookie ne sera envoyé à cet hôte.

Donc, vous pouvez toujours évitez en toute sécurité de traiter CSRF sur vos API REST. Mais votre serveur de connexion / authentification a intérêt à être à l'épreuve des balles (et protégé par CSRF).

Les points de terminaison de l'API Rest ont une différence très importante par rapport aux autres requêtes: ils sont spécifiquement sans état et ne doivent jamais accepter / utiliser les données d'un cookie ou d'une session.

Si c'est ainsi que vous définissez "REST API", alors aucun CSRF n'est possible. Le CSRF, également appelé «session riding» [ citation], ne fonctionnera évidemment pas s'il n'y a pas de session à «ride».

Réponse : Si vous stockez le jeton dans le localStorage et que vous l'ajoutez à vos requêtes avec JS, cela garantirait automatiquement la protection CSRF (par la nature de l'attaque)

Addendum : quant à savoir s'il est plus sûr d'utiliser des cookies http uniquement plutôt que localStorage (donner l'impression que cette façon d'avoir une protection CSRF créerait un problème en cas de XSS): ce n'est en fait pas . Cela rendrait juste un peu plus difficile pour l'attaquant qui contrôle JS sur votre site via un XSS exploité. @ Bobince a expliqué cela avec de meilleurs mots: Le paramètre httponly empêche-t-il de voler une session en utilisant XSS?

XSS est une vulnérabilité au niveau de l'application, mais ses effets peuvent être atténués en limitant la puissance du jeton grâce à l'utilisation de revendications (restreindre au minimum nécessaire)

Il y a une petite mise en garde spécifique aux réponses existantes que j'aimerais ajouter. Bien que Conor ait raison de dire que les cookies sont la seule forme de données d'authentification stockées localement envoyées avec toutes les demandes, ils ne sont pas la seule forme de données d'authentification stockées localement utilisées par les sites Web. Cela signifie que si un site décide de conserver ses jetons JWT / Session dans quelque chose comme LocalStorage ou SessionStorage, ceux-ci peuvent encore parfois être automatiquement retirés via javascript, puis utilisés sans interaction de l'utilisateur. Cela signifie qu'il est parfois encore possible d'effectuer des attaques CSRF "une fois supprimées" en redirigeant un utilisateur vers un URI frontal correspondant au domaine qui puis envoie les creds. Cela peut être accompli d'une manière plus directe si vous avez reflété XSS, mais il y a des cas où cela n'est pas nécessaire et de telles pages + scripts existent déjà.

Dans ces cas, le problème n'est pas le manque de Jetons CSRF sur l'API REST; c'est le manque de jetons sur les points de terminaison de n'importe quel frontend qui interagit avec lui.