Chrome, Firefox, Edge y otros están cambiando su comportamiento predeterminado de acuerdo con la propuesta de la IETF, las cookies incrementales, de modo que ocurra lo siguiente:
- Las cookies sin un atributo
SameSite
se tratan comoSameSite=Lax
, lo que significa que el comportamiento predeterminado es restringir las cookies solo a contextos propios. - Las cookies para el uso en varios sitios deben especificar
SameSite=None; Secure
para permitir la inclusión en el contexto de terceros.
Si aún no lo hiciste, debes actualizar los atributos de tus cookies de terceros para que no se bloqueen en el futuro.
Casos de uso para cookies de terceros o de sitios cruzados
Existen varios casos de uso y patrones comunes en los que las cookies deben enviarse en un contexto de terceros. Si proporcionas uno de estos casos de uso o dependes de ellos, asegúrate de que tú o el proveedor actualicen las cookies para que el servicio siga funcionando correctamente.
Contenido dentro de un <iframe>
El contenido de un sitio diferente que se muestra en un <iframe>
se encuentra en un contexto de terceros. Entre los casos de uso estándar, se incluyen los siguientes:
- Contenido incorporado que se comparte desde otros sitios, como videos, mapas, muestras de código y publicaciones de redes sociales
- Widgets de servicios externos, como pagos, calendarios, funciones de reserva y reservación.
- Widgets, como botones de redes sociales o servicios contra el fraude, que crean
<iframes>
menos evidentes.
Aquí se pueden usar cookies para, entre otras cosas, mantener el estado de la sesión, almacenar preferencias generales, habilitar estadísticas o personalizar el contenido para los usuarios con cuentas existentes.
Debido a que la Web es inherentemente componible, los <iframes>
también se usan para incorporar contenido que se ve en un contexto de nivel superior o propio. Todas las cookies que usa el sitio en el iframe se consideran cookies de terceros. Si estás creando sitios que deseas que otros sitios incorporen y necesitas cookies para que funcionen, también debes asegurarte de que estén marcadas para el uso entre sitios o de que puedas usar un resguardo sin ellas.
Solicitudes "no seguras" en varios sitios
Es posible que el término "no seguro" te preocupe, pero se refiere a cualquier solicitud que pueda tener como objetivo cambiar el estado. En la Web, esto se refiere principalmente a las solicitudes POST. Las cookies marcadas como SameSite=Lax
se envían en navegaciones seguras de nivel superior, como hacer clic en un vínculo para ir a un sitio diferente. Sin embargo, algo como el envío de <form>
a un sitio diferente con POST no incluye cookies.
Este patrón se usa para sitios que pueden redireccionar al usuario a un servicio remoto para realizar alguna operación antes de regresar, por ejemplo, redireccionar a un proveedor de identidad de terceros. Antes de que el usuario salga del sitio, se configura una cookie que contiene un token de uso único con la expectativa de que se pueda verificar en la solicitud que se muestra para mitigar los ataques de falsificación de solicitudes entre sitios (CSRF). Si esa solicitud de devolución se realiza a través de POST, deberás marcar las cookies como SameSite=None; Secure
.
Recursos remotos
Cualquier recurso remoto en una página, como el de las etiquetas <img>
o <script>
, puede depender de que se envíen cookies con una solicitud. Los casos de uso comunes incluyen los píxeles de seguimiento y la personalización de contenido.
Esto también se aplica a las solicitudes que se envían desde tu código JavaScript con fetch
o XMLHttpRequest
. Si se llama a fetch()
con la opción credentials: 'include'
, es probable que esas solicitudes incluyan cookies.
En el caso de XMLHttpRequest
, las cookies esperadas suelen indicarse con un valor withCredentials
para true
. Esas cookies deben marcarse de forma adecuada para que se incluyan en las solicitudes entre sitios.
Contenido dentro de un WebView
Un WebView en una app específica de la plataforma se ejecuta con un navegador. Los desarrolladores deben probar si las restricciones o los problemas que afectan a sus apps también se aplican a sus componentes WebView.
Android también permite que sus apps específicas de la plataforma establezcan cookies directamente con la API de CookieManager.
Al igual que con las cookies configuradas con encabezados o JavaScript, considera incluir SameSite=None; Secure
si están destinadas al uso entre sitios.
Cómo implementar SameSite
hoy
Marca las cookies que solo son necesarias en un contexto propio como SameSite=Lax
o SameSite=Strict
, según tus necesidades. Si no marcas estas cookies y, en su lugar, confías en el comportamiento predeterminado del navegador para controlarlas, es posible que se comporten de manera incoherente en los navegadores y, potencialmente, activen advertencias de la consola para cada cookie.
Set-Cookie: first_party_var=value; SameSite=Lax
Asegúrate de marcar como SameSite=None; Secure
las cookies necesarias en un contexto de terceros. Ambos atributos son obligatorios. Si solo especificas None
sin Secure
, se rechazará la cookie. Para tener en cuenta las diferencias en las implementaciones de navegadores, es posible que debas usar algunas de las estrategias de mitigación que se describen en Cómo controlar clientes incompatibles.
Set-Cookie: third_party_var=value; SameSite=None; Secure
Cómo controlar clientes incompatibles
Debido a que estos cambios para incluir None
y actualizar el comportamiento predeterminado aún son relativamente nuevos, los diferentes navegadores los manejan de diferentes maneras. Puedes consultar la página de actualizaciones en chromium.org para obtener una lista de problemas conocidos, pero es posible que esta lista no sea exhaustiva.
Una posible solución alternativa es configurar cada cookie en el estilo nuevo y el antiguo:
Set-cookie: 3pcookie=value; SameSite=None; Secure
Set-cookie: 3pcookie-legacy=value; Secure
Los navegadores que implementan el comportamiento más reciente establecen la cookie con el valor SameSite
. Los navegadores que no implementan el comportamiento nuevo ignoran ese valor y configuran la cookie 3pcookie-legacy
. Cuando procesas las cookies incluidas, tu sitio primero debe verificar la presencia del estilo nuevo de cookie y, luego, recurrir a la cookie heredada si no puede encontrar una nueva.
En el siguiente ejemplo, se muestra cómo hacerlo en Node.js, con el framework de Express y su middleware cookie-parser:
const express = require('express');
const cp = require('cookie-parser');
const app = express();
app.use(cp());
app.get('/set', (req, res) => {
// Set the new style cookie
res.cookie('3pcookie', 'value', { sameSite: 'none', secure: true });
// And set the same value in the legacy cookie
res.cookie('3pcookie-legacy', 'value', { secure: true });
res.end();
});
app.get('/', (req, res) => {
let cookieVal = null;
if (req.cookies['3pcookie']) {
// check the new style cookie first
cookieVal = req.cookies['3pcookie'];
} else if (req.cookies['3pcookie-legacy']) {
// otherwise fall back to the legacy cookie
cookieVal = req.cookies['3pcookie-legacy'];
}
res.end();
});
app.listen(process.env.PORT);
Este enfoque requiere que realices un trabajo adicional para configurar cookies redundantes y realizar cambios en el momento de configurar y leer la cookie. Sin embargo, debe abarcar a todos los navegadores, independientemente de su comportamiento, y mantener el funcionamiento de las cookies de terceros.
Como alternativa, puedes detectar al cliente con la cadena de usuario-agente cuando se envía un encabezado Set-Cookie
. Consulta la
lista de clientes incompatibles
y usa una biblioteca de detección de usuario-agente adecuada para tu plataforma, por
ejemplo, la biblioteca ua-parser-js
en Node.js. Este enfoque solo requiere que realices un cambio, pero es posible que el espionaje del usuario-agente no detecte a todos los usuarios afectados.
Compatibilidad con SameSite=None
en lenguajes, bibliotecas y frameworks
La mayoría de los lenguajes y bibliotecas admiten el atributo SameSite
para las cookies. Sin embargo, como la adición de SameSite=None
es relativamente reciente, es posible que debas evitar algunos comportamientos estándar por el momento.
Estos comportamientos se documentan en el repositorio de ejemplos de SameSite
en GitHub.
Cómo obtener ayuda
Las cookies se usan en todas partes de la Web, y es raro que un equipo de desarrollo tenga conocimiento completo de dónde las establece y usa su sitio, en especial en casos de uso entre sitios. Cuando encuentres un problema, es posible que sea la primera vez que alguien lo tenga, así que no dudes en comunicarte con nosotros:
- Informa un problema en el repositorio de ejemplos de
SameSite
en GitHub. - Haz una pregunta en la etiqueta "samesite" en StackOverflow.
- Si tienes problemas con el comportamiento de Chromium, informa un error en el sistema de seguimiento de errores de Chromium.
- Sigue el progreso de Chrome en la página de actualizaciones de
SameSite
.