Quels sont les cookies API?

Que sont les cookies d'API ?

Les cookies d'API sont de petites donnees qu'un serveur depose sur un client via des en-tetes de reponse HTTP et que le client renvoie lors des requetes suivantes vers le meme serveur. Dans un contexte d'API, les cookies transportent le plus souvent un identifiant de session ou un jeton d'authentification, afin qu'un serveur HTTP sans etat reconnaisse qui effectue chaque appel sans redemander d'identifiants a chaque fois. Comme HTTP est lui-meme sans etat, les cookies sont l'un des mecanismes les plus anciens et les plus repandus pour maintenir l'etat entre un client et une API.

Les cookies concernent quiconque construit ou teste des API. Un endpoint de connexion repond souvent avec un en-tete Set-Cookie, et chaque endpoint protege ensuite attend le retour du cookie. Si votre client d'API, votre moniteur ou votre script de test de charge ne conserve pas et ne renvoie pas correctement les cookies, les requetes authentifiees echouent alors que l'API se porte bien.

Comment les cookies fonctionnent avec les API

L'echange de cookies est un aller-retour simple base sur deux en-tetes HTTP. Quand un client envoie une requete, le serveur peut joindre un en-tete Set-Cookie a sa reponse. Le client stocke ce cookie et, a chaque requete suivante vers un domaine et un chemin correspondants, le renvoie dans un unique en-tete Cookie.

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

Le client le repete lors des appels suivants :

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

Le serveur recherche abc123 dans son magasin de sessions, retrouve l'utilisateur associe et autorise la requete.

Cookies de session et cookies persistants

• Cookies de session : sans attribut Expires ni Max-Age. Le client ne les garde que jusqu'a la fin de la session, puis les supprime. Ideals pour des connexions de courte duree.
• Cookies persistants : porteurs d'une date Expires ou d'un Max-Age en secondes. Le client les stocke et les renvoie jusqu'a expiration. Ils alimentent le "se souvenir de moi" et les preferences durables.

Pour les API, les cookies d'authentification sont le plus souvent lies a la session ou dotes d'un Max-Age court, car un identifiant durable pose un risque plus grand s'il est vole.

Attributs de cookie qui controlent le comportement

Attribut	Role
HttpOnly	Empeche JavaScript de lire le cookie via document.cookie, ce qui limite les degats d'une attaque XSS.
Secure	Demande au client de n'envoyer le cookie que sur HTTPS, jamais en clair.
SameSite	Controle l'envoi lors de requetes intersites. Valeurs Strict, Lax et None. Principale defense du navigateur contre le CSRF.
Domain	Definit quels hotes recoivent le cookie, y compris des sous-domaines comme api.example.com.
Path	Restreint le cookie aux URL sous un prefixe de chemin comme /api.
Expires / Max-Age	Fixe le moment de suppression. Sans valeur, il devient un cookie de session.

L'attribut SameSite merite une attention particuliere. Strict retient le cookie sur toute requete venant d'un autre site, Lax est la valeur par defaut moderne et ne l'autorise que sur les navigations de premier niveau, et None l'envoie partout mais exige Secure.

Auth par cookie et auth par jeton/bearer

Les API s'authentifient generalement de deux facons. L'auth par cookie (session) stocke un identifiant de session dans un cookie que le navigateur joint automatiquement. L'auth par jeton, comme un bearer token OAuth 2.0 ou un JSON Web Token (JWT), est envoyee explicitement par le client dans l'en-tete Authorization: Bearer <token>.

Aspect	Auth par cookie	Auth par jeton/bearer
Transport	En-tete Cookie automatique	En-tete Authorization manuel
Etat	Le serveur tient un magasin de sessions	Souvent jeton sans etat et autonome
Risque CSRF	Vulnerable, exige SameSite et un jeton CSRF	Non envoye seul, risque plus faible
Convient a	Apps navigateur sur un domaine	Apps mobiles, clients tiers, microservices

Aucune approche n'est meilleure dans l'absolu. Les cookies excellent pour les applications web de premier plan car HttpOnly garde l'identifiant hors de portee des scripts. Les bearer token excellent pour les clients mobiles et les appels entre services.

Considerations relatives au CSRF

La commodite des cookies, le fait que le navigateur les joigne automatiquement, est aussi leur faiblesse. Lors d'une attaque Cross-Site Request Forgery (CSRF), une page malveillante declenche une requete vers votre API et le navigateur y inclut le cookie de session de la victime. Definissez SameSite=Lax ou Strict et ajoutez un jeton CSRF que le serveur emet et que le client doit renvoyer dans un en-tete. Les API a bearer token evitent largement le CSRF, mais doivent alors stocker le jeton de facon sure contre le XSS.

Cookies dans REST et conception sans etat

REST, en tant que style d'architecture, valorise l'absence d'etat : chaque requete doit porter tout le necessaire, sans dependre d'un contexte cote serveur. Une session serveur referencee par un cookie assouplit ce principe. En pratique, de nombreuses equipes utilisent des cookies pour le frontend web et des bearer token sans etat pour l'acces programmatique.

Gestion des cookies dans les clients d'API et les outils de test

Tout outil qui appelle une API authentifiee doit gerer les cookies comme un navigateur : capturer Set-Cookie dans les reponses, les stocker et renvoyer l'en-tete Cookie approprie lors des requetes suivantes. La plupart des bibliotheques HTTP offrent un conteneur de cookies, et des outils comme curl proposent les options --cookie-jar et --cookie.

Cela compte directement pour la supervision et les tests de performance. Un moniteur d'API qui verifie un endpoint connecte doit d'abord executer l'etape de connexion, conserver le cookie de session renvoye et l'envoyer sur l'appel protege, sinon il enregistre un 401 et vous alerte pour une panne inexistante. Il en va de meme pour les tests de charge : un test de charge realiste connecte un utilisateur virtuel et donne a chaque utilisateur simule son propre conteneur de cookies. Avec LoadFocus, vous pouvez scripter ces parcours multi-etapes et conscients des cookies dans JMeter ou k6, afin d'exercer les parcours authentifies comme les vit un utilisateur reel.

Bonnes pratiques et securite

• Activez toujours HttpOnly sur les cookies d'authentification.
• Activez Secure et servez l'API en HTTPS.
• Utilisez SameSite=Lax comme base et Strict pour les actions sensibles.
• Gardez des sessions courtes et renouvelez les identifiants a la connexion et a la deconnexion.
• Ne stockez qu'un identifiant opaque dans le cookie, jamais de donnees sensibles.
• Associez l'auth par cookie a un jeton CSRF pour toute requete modifiant l'etat.

FAQ sur les cookies d'API

Quelle est la difference entre un cookie et un jeton dans une API ?

Un cookie est joint automatiquement par le navigateur et pointe souvent vers une session serveur, tandis qu'un bearer token est envoye manuellement dans l'en-tete Authorization et est souvent autonome. Les cookies conviennent aux apps web, les jetons aux clients mobiles et de service.

Les cookies sont-ils surs pour l'authentification d'API ?

Oui, s'ils sont bien configures. Utilisez HttpOnly, Secure et SameSite plus un jeton CSRF. Un cookie sans ces drapeaux est un vrai risque.

Que fait l'attribut SameSite ?

Il controle si un cookie est envoye lors de requetes intersites. Strict jamais, Lax seulement sur les navigations de premier niveau et None partout mais avec Secure. C'est la principale defense contre le CSRF.

Pourquoi mon moniteur ou test de charge recoit-il un 401 alors que la connexion fonctionne ?

En general, l'outil ne conserve pas le cookie de session entre les requetes. Capturez le Set-Cookie de la reponse de connexion et renvoyez-le sur les appels proteges, avec un conteneur de cookies propre a chaque utilisateur virtuel.

Une API REST peut-elle utiliser des cookies ?

Oui, meme si une session serveur referencee par cookie assouplit le principe sans etat de REST. Beaucoup d'equipes utilisent des cookies pour le frontend et des bearer token sans etat pour l'acces programmatique.

Quelle est la difference entre un cookie de session et un cookie persistant ?

Un cookie de session n'a pas d'expiration et disparait a la fin de la session, tandis qu'un cookie persistant possede Expires ou Max-Age et dure jusque-la. Les cookies d'auth sont souvent courts pour limiter le risque en cas de vol.