¿Qué son las cookies de API? Definición y seguridad

¿Qué son las cookies de API?

Las cookies de API son pequeños pares nombre-valor que un servidor de API establece con la cabecera de respuesta Set-Cookie y que el cliente devuelve en la cabecera de petición Cookie en llamadas posteriores al mismo host. Lo habitual es que la cookie contenga un identificador de sesión opaco, de modo que un servidor HTTP sin estado reconozca a quien ya inició sesión sin pedir credenciales en cada petición.

Las cookies importan siempre que llamas o pruebas una API autenticada. Si un cliente, un monitor o un script de prueba de carga pierde la cookie tras el login, cada llamada protegida falla con un 401 aunque la API esté sana.

Cómo funcionan las cookies con las APIs

El intercambio es un viaje de ida y vuelta con dos cabeceras. La respuesta del login establece la cookie:

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

El cliente la guarda y la reenvía en cada petición que coincida. Varias cookies viajan en una sola cabecera, separadas por punto y coma y un espacio:

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

El servidor busca abc123 en su almacén de sesiones, encuentra al usuario y autoriza la llamada. Según la referencia de MDN sobre Set-Cookie, una cookie sin Expires ni Max-Age es una cookie de sesión y dura hasta que el cliente se cierra. Si se definen ambos, manda Max-Age. El borrador actual de RFC 6265bis recomienda que los navegadores limiten la vida útil a 400 días.

Atributos de cookie que importan

SameSite=Strict retiene la cookie en cualquier petición entre sitios. Lax la envía en navegaciones de nivel superior con un método seguro como GET, pero no en llamadas en segundo plano entre sitios. Algunos navegadores aplican Lax cuando falta el atributo, así que indícalo de forma explícita en lugar de depender de eso. Los prefijos de nombre endurecen más las reglas: una cookie __Host- debe ser Secure, tener Path=/ y no llevar Domain.

Autenticación por cookie frente a tokens bearer

Las APIs suelen autenticar de una de dos formas. La autenticación por cookie (sesión) guarda un id de sesión en una cookie que el navegador adjunta solo. La autenticación por token, como un token bearer o un JWT, se envía de forma explícita en la cabecera Authorization.

Ninguna es mejor sin más, y muchos sistemas usan las dos. Una clave de API de larga duración es una tercera opción para el acceso de servidor a servidor. Para ver el panorama de ataques y controles, consulta seguridad de API.

CSRF: el precio de las cookies automáticas

Como el navegador adjunta las cookies por su cuenta, una página maliciosa puede hacer que el navegador de la víctima envíe a tu API una petición con la cookie de sesión incluida. Es la falsificación de petición en sitios cruzados (CSRF). Las defensas se suman: SameSite=Lax o Strict, un token CSRF que el cliente debe devolver en una cabecera o campo del cuerpo, y comprobar la cabecera Origin en las peticiones que modifican datos. Las APIs con token bearer evitan en gran parte el CSRF, pero entonces el token debe guardarse a salvo de XSS.

Cookies en monitorización de API y pruebas de carga

Una herramienta que llama a una API autenticada debe comportarse como un navegador: capturar Set-Cookie de la respuesta del login, guardarla y enviar después la cabecera Cookie correspondiente. La mayoría de las librerías HTTP ofrecen un cookie jar, y curl tiene --cookie-jar y --cookie.

En una prueba de carga, cada usuario virtual necesita su propio cookie jar, rellenado con su propio login, para que las sesiones no choquen. El HTTP Cookie Manager de JMeter mantiene un almacén de cookies separado para cada hilo, y LoadFocus ejecuta tus archivos JMX existentes en la nube, así que esa configuración se mantiene. En APIs con token, la monitorización de API de LoadFocus puede iniciar sesión, pasar el token devuelto a la siguiente petición y comprobar cada paso. Las auditorías de velocidad de páginas con sesión iniciada pueden enviar una cookie de sesión como cabecera personalizada con la monitorización de velocidad de página. Más sobre flujos de prueba autenticados (en inglés): pruebas de carga con OAuth2 y escenarios de carga realistas para e-commerce. Para lo básico de las comprobaciones de API, lee pruebas de API.

Errores frecuentes

• Perder la cookie tras el login en un script o monitor y luego perseguir una caída fantasma llena de respuestas 401.
• Compartir un cookie jar entre todos los usuarios virtuales, de modo que miles de usuarios simulados parecen una sola sesión.
• Usar SameSite=None sin Secure: los navegadores rechazan la cookie.
• Probar una cookie Secure por HTTP plano, donde nunca se envía (salvo en localhost).
• Guardar datos del usuario en la cookie en vez de un id opaco, o mantener sesiones vivas durante semanas.
• Confiar solo en cookies para peticiones que modifican datos, sin token CSRF.

Preguntas frecuentes sobre las cookies de API

¿Cuál es la diferencia entre una cookie y un token en una API?

Una cookie la adjunta el navegador automáticamente y suele apuntar a una sesión en el servidor. Un token bearer se envía de forma explícita en la cabecera Authorization y a menudo es autocontenido. Las cookies encajan en apps web propias, los tokens en apps móviles y clientes de servicio.

¿Son seguras las cookies para autenticar una API?

Pueden serlo si se configuran bien. Usa HttpOnly contra el acceso de scripts, Secure para forzar HTTPS, SameSite más un token CSRF contra peticiones falsificadas y una vida útil corta. Una cookie sin esos ajustes es un riesgo real.

¿Qué hace el atributo SameSite?

Controla si una cookie se envía en peticiones entre sitios. Strict nunca la envía entre sitios, Lax solo en navegaciones de nivel superior con método seguro, y None siempre, aunque exige Secure.

¿Por qué mi monitor de API o prueba de carga recibe un 401 tras un login correcto?

Normalmente la herramienta no conserva la cookie de sesión. Captura Set-Cookie de la respuesta del login y envíala en cada llamada protegida, con un cookie jar por usuario virtual.

¿Puede una API REST usar cookies?

Sí, pero una sesión en el servidor detrás de una cookie relaja la ausencia de estado de REST. Muchos equipos usan cookies para el front end del navegador y tokens bearer para el acceso programático.