Que sont les cookies d'API ? Définition et sécurité

Que sont les cookies d'API ?

Les cookies d'API sont de petites paires nom-valeur qu'un serveur d'API définit avec l'en-tête de réponse Set-Cookie et que le client renvoie dans l'en-tête de requête Cookie lors des appels suivants vers le même hôte. Le plus souvent, le cookie contient un identifiant de session opaque, ce qui permet à un serveur HTTP sans état de reconnaître un appelant connecté sans redemander ses identifiants à chaque requête.

Les cookies comptent dès que vous appelez ou testez une API authentifiée. Si un client, un moniteur ou un script de test de charge perd le cookie après la connexion, chaque appel protégé échoue avec un 401 alors que l'API est en bonne santé.

Comment les cookies fonctionnent avec les API

L'échange est un aller-retour sur deux en-têtes. La réponse de connexion définit le cookie :

HTTP/1.1 200 OK
Set-Cookie: sessionId=abc123; Path=/; HttpOnly; Secure; SameSite=Lax

Le client le stocke et le renvoie à chaque requête correspondante. Plusieurs cookies voyagent dans un seul en-tête, séparés par un point-virgule et une espace :

GET /api/v1/orders HTTP/1.1
Host: api.example.com
Cookie: sessionId=abc123; theme=dark

Le serveur recherche abc123 dans son stockage de sessions, retrouve l'utilisateur et autorise l'appel. D'après la référence MDN sur Set-Cookie, un cookie sans Expires ni Max-Age est un cookie de session, valable jusqu'à l'arrêt du client. Si les deux sont définis, Max-Age l'emporte. Le brouillon actuel de la RFC 6265bis recommande que les navigateurs plafonnent la durée de vie à 400 jours.

Les attributs de cookie qui comptent

SameSite=Strict retient le cookie sur toute requête intersite. Lax l'envoie lors des navigations de premier niveau avec une méthode sûre comme GET, mais pas sur les appels intersites en arrière-plan. Certains navigateurs appliquent Lax quand l'attribut est absent : indiquez-le donc explicitement plutôt que de compter là-dessus. Les préfixes de nom durcissent encore les règles : un cookie __Host- doit être Secure, avoir Path=/ et ne pas porter de Domain.

Authentification par cookie ou par jeton bearer

Les API s'authentifient en général de deux façons. L'authentification par cookie (session) garde un identifiant de session dans un cookie que le navigateur joint tout seul. L'authentification par jeton, comme un jeton bearer ou un JWT, est envoyée explicitement dans l'en-tête Authorization.

Aucune n'est meilleure en soi, et beaucoup de systèmes utilisent les deux. Une clé d'API de longue durée est une troisième option pour l'accès de serveur à serveur. Pour une vue d'ensemble des attaques et des contrôles, voir sécurité des API.

CSRF : le prix des cookies automatiques

Comme le navigateur joint les cookies de lui-même, une page malveillante peut faire envoyer par le navigateur de la victime une requête à votre API avec le cookie de session. C'est la falsification de requête intersite (CSRF). Les défenses se cumulent : SameSite=Lax ou Strict, un jeton CSRF que le client doit renvoyer dans un en-tête ou un champ du corps, et la vérification de l'en-tête Origin sur les requêtes qui modifient des données. Les API à jeton bearer évitent en grande partie le CSRF, mais le jeton doit alors être stocké à l'abri du XSS.

Cookies, supervision d'API et tests de charge

Un outil qui appelle une API authentifiée doit se comporter comme un navigateur : récupérer Set-Cookie dans la réponse de connexion, le stocker, puis envoyer l'en-tête Cookie correspondant. La plupart des bibliothèques HTTP offrent un cookie jar, et curl propose --cookie-jar et --cookie.

Dans un test de charge, chaque utilisateur virtuel a besoin de son propre cookie jar, rempli par sa propre connexion, pour que les sessions ne se mélangent pas. Le HTTP Cookie Manager de JMeter garde un stockage de cookies distinct pour chaque thread, et LoadFocus exécute vos fichiers JMX existants dans le cloud, cette configuration est donc conservée. Pour les API à jeton, la supervision d'API LoadFocus peut se connecter, transmettre le jeton reçu à la requête suivante et vérifier chaque étape. Les audits de vitesse de pages connectées peuvent envoyer un cookie de session comme en-tête personnalisé avec la surveillance de la vitesse des pages. Plus sur les parcours de test authentifiés (en anglais) : tests de charge OAuth2 et scénarios de charge réalistes pour l'e-commerce. Pour les bases des contrôles d'API, lisez tests d'API.

Erreurs fréquentes

• Perdre le cookie après la connexion dans un script ou un moniteur, puis courir après une panne fantôme faite de réponses 401.
• Partager un seul cookie jar entre tous les utilisateurs virtuels : des milliers d'utilisateurs simulés ressemblent à une seule session.
• Définir SameSite=None sans Secure : les navigateurs rejettent le cookie.
• Tester un cookie Secure en HTTP simple, où il n'est jamais envoyé (localhost excepté).
• Mettre des données utilisateur dans le cookie au lieu d'un identifiant opaque, ou garder des sessions actives pendant des semaines.
• Ne compter que sur les cookies pour les requêtes qui modifient des données, sans jeton CSRF.

Questions fréquentes sur les cookies d'API

Quelle est la différence entre un cookie et un jeton dans une API ?

Un cookie est joint automatiquement par le navigateur et renvoie en général à une session côté serveur. Un jeton bearer est envoyé explicitement dans l'en-tête Authorization et il est souvent autonome. Les cookies conviennent aux applications web propriétaires, les jetons aux applications mobiles et aux clients de service.

Les cookies sont-ils sûrs pour authentifier une API ?

Ils peuvent l'être, s'ils sont bien configurés. Utilisez HttpOnly contre l'accès par script, Secure pour imposer HTTPS, SameSite plus un jeton CSRF contre les requêtes falsifiées, et une durée de vie courte. Un cookie sans ces réglages est un vrai risque.

À quoi sert l'attribut SameSite ?

Il détermine si un cookie est envoyé avec les requêtes intersites. Strict ne l'envoie jamais en intersite, Lax seulement lors des navigations de premier niveau avec une méthode sûre, et None toujours, mais il exige Secure.

Pourquoi mon moniteur d'API ou mon test de charge reçoit-il un 401 après une connexion réussie ?

Le plus souvent, l'outil ne conserve pas le cookie de session. Récupérez Set-Cookie dans la réponse de connexion et envoyez-le à chaque appel protégé, avec un cookie jar par utilisateur virtuel.

Une API REST peut-elle utiliser des cookies ?

Oui, mais une session côté serveur derrière un cookie assouplit l'absence d'état de REST. Beaucoup d'équipes utilisent des cookies pour le front end du navigateur et des jetons bearer pour l'accès programmatique.