Las cookies seguras son cookies HTTP con atributos especiales que mejoran la seguridad. El indicador 'Secure' garantiza que las cookies solo se envíen a través de conexiones HTTPS, mientras que 'HttpOnly' impide el acceso de JavaScript a las cookies, protegiendo contra los ataques XSS. El atributo 'SameSite' ayuda a prevenir los ataques CSRF al controlar cómo se envían las cookies en las solicitudes entre sitios.
Las cookies seguras son cookies HTTP corrientes reforzadas con atributos protectores. El flag Secure le indica al navegador que envíe la cookie solo por HTTPS, nunca por HTTP plano. HttpOnly oculta la cookie a JavaScript, de modo que document.cookie no puede leerla. SameSite (Lax, Strict o None) controla si la cookie se adjunta a las peticiones entre sitios, lo que limita su uso en la falsificación de peticiones entre sitios. Un refuerzo adicional incluye cookies de solo host o prefijos de nombre __Host- y __Secure-, un ámbito estricto de Path y Domain, y caducidades cortas. En conjunto, estos atributos reducen cómo, cuándo y por quién puede accederse o reproducirse una cookie, a menudo un identificador de sesión.
Las cookies de sesión son muy valiosas: quien posee una a menudo puede actuar como el usuario que ha iniciado sesión. Cada atributo cierra una vía de robo concreta. Sin Secure, una sola petición por HTTP puede filtrar la cookie a un espía de la red. Sin HttpOnly, cualquier payload de cross-site scripting exitoso puede leer la cookie y exfiltrarla. Sin SameSite, un sitio malicioso puede desencadenar en silencio peticiones autenticadas en el navegador de la víctima. Ninguno de estos atributos basta por sí solo; una cookie necesita la combinación adecuada para su propósito. Configurarlos bien es uno de los pasos más baratos y eficaces de la seguridad de sesiones web, y la mala configuración es un hallazgo común en las auditorías.
Establece Secure y HttpOnly en cada cookie de sesión y de autenticación, elige SameSite=Lax o Strict a menos que una necesidad genuina entre sitios obligue a None (que entonces requiere Secure), y prefiere el prefijo __Host- para las cookies de sesión para blindar dominio y ruta. Combina esto con HTTPS en todas partes y HSTS. Los atributos limitan la exfiltración, pero no detienen la inyección que roba la cookie en primer lugar: un fallo de cross-site scripting todavía puede realizar acciones dentro de la sesión incluso sin leer la cookie. cside detecta y puede bloquear el comportamiento malicioso de los scripts a nivel de carga útil, abordando la vía de inyección que los flags de las cookies por sí solos dejan abierta.
No. Secure solo controla el transporte: impide que el navegador envíe la cookie por HTTP sin cifrar. El valor en sí no queda cifrado ni firmado por el flag. Si el contenido es sensible, el servidor debe cifrarlo o firmarlo por separado o, mejor aún, almacenar solo un identificador de sesión opaco e imposible de adivinar.
Apuntan a amenazas distintas. Secure rige qué transporte lleva la cookie, HttpOnly rige si JavaScript puede leerla y SameSite rige si la cookie acompaña a las peticiones entre sitios. SameSite mitiga sobre todo la falsificación de peticiones entre sitios, mientras que HttpOnly mitiga sobre todo el robo mediante cross-site scripting. Las cookies robustas suelen establecer los tres.
We answer client-side security questions every day. Bring yours.