¿Qué son las cookies API?

Que son las cookies de API?

Las cookies de API son pequenas piezas de datos que un servidor establece en un cliente mediante cabeceras de respuesta HTTP y que el cliente devuelve en peticiones posteriores al mismo servidor. En el contexto de una API, las cookies suelen transportar un identificador de sesion o un token de autenticacion para que un servidor HTTP sin estado reconozca quien hace cada llamada sin pedir credenciales cada vez. Como HTTP es sin estado, las cookies son uno de los mecanismos mas antiguos y extendidos para mantener el estado entre un cliente y una API.

Las cookies importan a cualquiera que construya o pruebe APIs. Un endpoint de login suele responder con una cabecera Set-Cookie, y cada endpoint protegido despues espera que la cookie regrese. Si tu cliente de API, monitor o script de prueba de carga no guarda y reenvia las cookies correctamente, las peticiones autenticadas fallan aunque la API este sana.

Como funcionan las cookies con las APIs

El intercambio de cookies es un viaje de ida y vuelta sobre dos cabeceras HTTP. Cuando un cliente envia una peticion, el servidor puede adjuntar una cabecera Set-Cookie a su respuesta. El cliente guarda esa cookie y, en cada peticion posterior a un dominio y ruta coincidentes, la devuelve en una unica cabecera Cookie.

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

El cliente lo repite en las llamadas siguientes:

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

El servidor busca abc123 en su almacen de sesiones, encuentra al usuario asociado y autoriza la peticion.

Cookies de sesion frente a cookies persistentes

• Cookies de sesion: no tienen atributo Expires ni Max-Age. El cliente las conserva solo hasta que termina la sesion y luego las descarta. Ideales para inicios de sesion de corta duracion.
• Cookies persistentes: llevan una fecha Expires o un Max-Age en segundos. El cliente las guarda y las devuelve hasta que caducan. Impulsan el "recordarme" y las preferencias de larga vida.

En las APIs, las cookies de autenticacion suelen ser de sesion o con un Max-Age corto, porque una credencial de larga vida en el cliente es un riesgo mayor si te la roban.

Atributos de cookie que controlan el comportamiento

Atributo	Proposito
HttpOnly	Impide que JavaScript lea la cookie mediante document.cookie, limitando el dano de un ataque XSS.
Secure	Indica al cliente enviar la cookie solo por HTTPS, para que nunca viaje en texto plano.
SameSite	Controla el envio en peticiones entre sitios. Valores Strict, Lax y None. Es la principal defensa del navegador contra CSRF.
Domain	Define que hosts reciben la cookie, incluidos subdominios como api.example.com.
Path	Restringe la cookie a URLs bajo un prefijo de ruta como /api.
Expires / Max-Age	Fija cuando se elimina la cookie. Sin valor, se convierte en cookie de sesion.

El atributo SameSite merece atencion especial. Strict retiene la cookie en cualquier peticion originada en otro sitio, Lax es el valor por defecto moderno y la permite solo en navegaciones de nivel superior, y None la envia a todas partes pero exige Secure.

Auth por cookie frente a auth por token/bearer

Las APIs suelen autenticar de dos formas. La auth por cookie (sesion) guarda un identificador de sesion en una cookie que el navegador adjunta automaticamente. La auth por token, como un bearer token de OAuth 2.0 o un JSON Web Token (JWT), la envia el cliente de forma explicita en la cabecera Authorization: Bearer <token>.

Aspecto	Auth por cookie	Auth por token/bearer
Transporte	Cabecera Cookie automatica	Cabecera Authorization manual
Estado	El servidor mantiene un almacen de sesiones	A menudo token sin estado y autonomo
Riesgo CSRF	Vulnerable, necesita SameSite y token CSRF	No se envia solo, menor riesgo
Mejor para	Apps de navegador en un dominio	Apps moviles, clientes externos, microservicios

Ninguno es mejor en terminos absolutos. Las cookies brillan en apps web de origen propio porque HttpOnly mantiene la credencial fuera del alcance de los scripts. Los bearer token brillan en clientes moviles y llamadas entre servicios.

Consideraciones sobre CSRF

La comodidad de las cookies, que el navegador las adjunta solo, es tambien su debilidad. En un ataque de Cross-Site Request Forgery (CSRF), una pagina maliciosa dispara una peticion a tu API y el navegador incluye la cookie de sesion de la victima. Establece SameSite=Lax o Strict y anade un token CSRF que el servidor emite y el cliente debe devolver en una cabecera. Las APIs con bearer token evitan en gran medida el CSRF, pero cargan con guardar el token de forma segura frente a XSS.

Cookies en REST y diseno sin estado

REST como estilo arquitectonico valora la ausencia de estado: cada peticion debe llevar todo lo necesario, sin depender de contexto en el servidor. Una sesion en el servidor referenciada por una cookie flexibiliza ese principio. En la practica, muchos equipos usan cookies para el frontend web y bearer token sin estado para el acceso programatico.

Manejo de cookies en clientes de API y herramientas de prueba

Cualquier herramienta que llame a una API autenticada debe gestionar las cookies como un navegador: capturar Set-Cookie de las respuestas, guardarlas y reenviar la cabecera Cookie adecuada en peticiones posteriores. La mayoria de las librerias HTTP ofrecen un contenedor de cookies, y herramientas como curl tienen las opciones --cookie-jar y --cookie.

Esto importa directamente para el monitoreo y las pruebas de rendimiento. Un monitor de API que revisa un endpoint con sesion iniciada debe ejecutar primero el login, conservar la cookie de sesion devuelta y enviarla en la llamada protegida, o registrara un 401 y te alertara por una caida que no existe. Lo mismo aplica a las pruebas de carga: una prueba de carga realista inicia sesion a un usuario virtual y da a cada usuario simulado su propio contenedor de cookies. Con LoadFocus puedes programar estos flujos de varios pasos y conscientes de cookies en JMeter o k6, para ejercitar los recorridos autenticados como los vive un usuario real.

Buenas practicas y seguridad

• Activa siempre HttpOnly en las cookies de autenticacion.
• Activa Secure y sirve la API por HTTPS.
• Usa SameSite=Lax como base y Strict para acciones sensibles.
• Manten sesiones cortas y renueva los identificadores en login y logout.
• Guarda solo un identificador opaco en la cookie, nunca datos sensibles.
• Combina la auth por cookie con un token CSRF en cada peticion que cambie estado.

FAQ sobre cookies de API

Cual es la diferencia entre una cookie y un token en una API?

Una cookie la adjunta el navegador de forma automatica y suele apuntar a una sesion del servidor, mientras que un bearer token se envia manualmente en la cabecera Authorization y suele ser autonomo. Las cookies encajan en apps web, los tokens en clientes moviles y de servicio.

Son seguras las cookies para autenticar una API?

Si, con la configuracion correcta. Usa HttpOnly, Secure y SameSite mas un token CSRF. Una cookie sin estos indicadores es un riesgo real.

Que hace el atributo SameSite?

Controla si una cookie se envia en peticiones entre sitios. Strict nunca, Lax solo en navegaciones de nivel superior y None a todas partes pero con Secure. Es la principal defensa contra CSRF.

Por que mi monitor o prueba de carga recibe un 401 si el login funciona?

Normalmente la herramienta no conserva la cookie de sesion entre peticiones. Captura el Set-Cookie de la respuesta de login y reenvialo en las llamadas protegidas, con un contenedor de cookies propio por usuario virtual.

Puede una API REST usar cookies?

Puede, aunque una sesion en servidor referenciada por cookie relaja el principio sin estado de REST. Muchos equipos usan cookies para el frontend y bearer token sin estado para el acceso programatico.

Cual es la diferencia entre una cookie de sesion y una persistente?

Una cookie de sesion no tiene caducidad y desaparece al terminar la sesion, mientras que una persistente tiene Expires o Max-Age y dura hasta ese momento. Las cookies de auth suelen ser cortas para limitar el riesgo si te las roban.