Sécurisation des API REST

Prenez la configuration d'une application web classique, pointez un client JavaScript dessus, et observez : au lieu d'un 401 propre, votre appel fetch reçoit un 302 vers une page de connexion HTML. Le client, qui attendait du JSON, essaie d'analyser du HTML et échoue avec un message incompréhensible. Rien n'est cassé pour autant — Spring Security fait exactement ce qu'on lui a demandé, à savoir se comporter comme si un navigateur suivait un parcours de connexion.

C'est le premier ajustement à faire : une API ne redirige pas, elle répond par un code. Le deuxième concerne l'état. Une application à session stocke l'identité côté serveur et la retrouve via un cookie ; une API sans état exige que chaque requête porte sa propre preuve d'identité. Les deux modèles fonctionnent, mais ils n'ont pas les mêmes vulnérabilités, et les protections adaptées à l'un ne le sont pas à l'autre.

C'est là que se produisent les deux erreurs les plus répandues du domaine. La première consiste à copier csrf.disable() sans se demander ce qui rendait cette protection nécessaire — et à la désactiver aussi sur les parties de l'application qui utilisent des cookies. La seconde consiste à traiter CORS comme un mécanisme de sécurité, alors qu'il n'en est pas un, et à ouvrir un accès en croyant le contrôler.