Sécuriser une API Laravel avec Sanctum : guide complet

Sécuriser une API n’est pas qu’une question d’ajouter un middleware d’authentification. Laravel Sanctum offre un système léger pour authentifier des SPA, des applications mobiles ou distribuer des tokens API, mais encore faut-il le configurer correctement. Voici les points essentiels pour sécuriser une API Laravel avec Sanctum.

Sommaire

1. Pourquoi Sanctum plutôt que Passport
2. Authentifier une SPA (Single Page Application)
3. Distribuer des tokens API
4. Limiter les permissions avec les « abilities »
5. CORS et cookies : les pièges classiques
6. Bonnes pratiques complémentaires

Pourquoi Sanctum plutôt que Passport

Laravel propose historiquement deux solutions d’authentification API : Passport (implémentation complète d’OAuth2) et Sanctum (plus léger). Passport est pertinent quand l’application doit réellement jouer le rôle d’un fournisseur OAuth2 (autoriser des applications tierces à agir au nom d’un utilisateur). Pour l’immense majorité des cas — authentifier son propre frontend SPA, une application mobile, ou distribuer des tokens API à des utilisateurs pour leurs propres scripts — Sanctum est plus simple à mettre en place et suffisant.

Authentifier une SPA (Single Page Application)

Pour une SPA servie sur le même domaine (ou un sous-domaine) que l’API Laravel, Sanctum utilise l’authentification par cookies de session, protégée par le mécanisme CSRF standard de Laravel plutôt que par des tokens Bearer. Le frontend doit d’abord requêter /sanctum/csrf-cookie pour obtenir le cookie de protection CSRF, avant tout appel d’authentification. Les domaines autorisés à utiliser ce mode doivent être déclarés explicitement dans la configuration (SANCTUM_STATEFUL_DOMAINS), ce qui évite qu’un domaine non prévu ne bénéficie de l’authentification par cookie.

Distribuer des tokens API

Pour les applications mobiles ou les intégrations tierces sans état partagé (pas de cookies), Sanctum permet de générer des tokens personnels via $user->createToken('nom-du-token'). Ce token est envoyé une seule fois au client, qui doit ensuite l’inclure dans l’en-tête Authorization: Bearer de chaque requête. Ces tokens sont stockés en base sous forme hachée, ce qui signifie qu’ils ne peuvent pas être retrouvés en clair après leur génération — seul le client qui l’a reçu la première fois le connaît.

Limiter les permissions avec les « abilities »

Chaque token Sanctum peut se voir attribuer des « abilities » (capacités), une liste de permissions associées au token plutôt qu’à l’utilisateur dans son ensemble. Un token créé avec ['posts:read'] ne devrait pouvoir accéder qu’aux routes qui vérifient explicitement cette capacité via $request->user()->tokenCan('posts:read'). C’est un principe de moindre privilège appliqué au niveau du token : même si un token fuite, son usage reste limité à ce pour quoi il a été émis.

CORS et cookies : les pièges classiques

L’authentification SPA par cookies impose une configuration CORS précise : supports_credentials doit être activé côté Laravel, et le frontend doit envoyer ses requêtes avec withCredentials: true (ou l’équivalent selon le client HTTP utilisé). Un oubli fréquent est de configurer un domaine générique (*) pour les origines autorisées : cela est incompatible avec les cookies d’authentification, qui exigent une liste d’origines explicite. De même, en production, les cookies doivent être marqués Secure et servis exclusivement en HTTPS.

Bonnes pratiques complémentaires

Au-delà de la configuration de Sanctum lui-même, quelques principes restent valables pour toute API Laravel : limiter le taux de requêtes (rate limiting) sur les routes d’authentification pour freiner le brute force, invalider les tokens obsolètes ou inutilisés, journaliser les tentatives d’authentification échouées, et ne jamais renvoyer d’informations différenciées entre « utilisateur inexistant » et « mot de passe incorrect » dans les messages d’erreur, afin de ne pas faciliter l’énumération de comptes.

Chez Any In IT, nous concevons et sécurisons des API Laravel pour des applications SPA, mobiles et des intégrations tierces, en appliquant ces principes dès la conception plutôt qu’en correction a posteriori.