¿Cómo utilizarías CHIPS para aislar sesiones en un widget embebido entre sitios?

Pregunta y escenario

El widget es servido por support.example y está embebido en sitios de nivel superior como shop-a.example y shop-b.example. Debe mantener una sesión a través de las páginas de productos, pago (checkout) y ayuda bajo shop-a.example, mientras que shop-b.example recibe un estado aislado. El diseño debe contemplar las cookies de terceros restringidas, navegadores antiguos, cierre de sesión, transferencia a un agente y múltiples pestañas.

Qué evalúa el entrevistador

• ¿Entiende el candidato que CHIPS indexa una cookie tanto por el sitio de nivel superior como por el origen embebido?
• ¿Puede distinguir el estado persistente por sitio del estado de terceros no particionado que requiere el permiso del usuario?
• ¿Puede conectar el diseño de cookies, las sesiones de servidor, CSRF, la protección contra reproducción (replay) y el cierre de sesión en un único flujo de datos?
• ¿Cubre la detección de capacidades, el soporte para navegadores heredados (fallback), las claves de caché y la observabilidad?

Preguntas de clarificación para hacer primero

Confirma HTTPS, si el widget debe identificar a una misma persona a través de diferentes sitios de nivel superior, si los subdominios comparten sesión y si es aceptable una página de inicio de sesión de nivel superior. Clarifica la sensibilidad de los datos, la duración de la sesión, el push desde el servidor y los navegadores objetivo. Si el negocio realmente necesita identidad entre sitios, CHIPS por sí solo no es el mecanismo adecuado; utiliza un inicio de sesión o autorización explícita.

Estructura de respuesta en 30 segundos

Definiría la sesión como perteneciente a un único sitio de nivel superior. El widget establece una cookie segura con Partitioned, y el servidor resuelve el estado utilizando el sitio de nivel superior y la sesión del widget; los subdominios de un sitio comparten esa partición, mientras que otro sitio obtiene una diferente. La cookie no es una credencial de identidad entre sitios. El inicio de sesión entre sitios utiliza un flujo de autorización de nivel superior. Cuando CHIPS no esté disponible, se ejecuta sin estado persistente o se solicita al usuario que autorice explícitamente. Verifica el cierre de sesión, CSRF, el aislamiento de caché y el comportamiento en múltiples pestañas de extremo a extremo.

Análisis detallado paso a paso

1. Definir el límite de confianza. Trata el sitio que embebe el widget como un contexto de partición, no como una decisión de autorización derivada de una cadena Origin. Mantén una lista de permitidos y valida el origen del mensaje, el tenant y el estado de la sesión.
2. Establecer una cookie particionada. Utiliza Secure, un valor apropiado de SameSite y Partitioned; prefiere el prefijo __Host al vincularla al host actual. La clave lógica de la cookie incluye el origen embebido y el sitio de nivel superior, por lo que el mismo widget no puede leer una cookie a través de dos sitios de nivel superior.
3. Diseñar la sesión en el servidor. Almacena únicamente un identificador opaco aleatorio en la cookie. La sesión en el servidor registra el tenant, el sitio de nivel superior, la hora de creación, la expiración y la versión de revocación. Vuelve a verificar la vinculación en cada solicitud en lugar de confiar únicamente en el particionamiento del navegador.
4. Manejar subdominios y cachés. Los subdominios pueden reutilizar una partición de nivel superior, pero las claves de caché de HTML, scripts y API deben incluir la variación de tenant o sesión. Utiliza almacenamiento en caché privado o una política explícita de Vary para respuestas personalizadas; nunca permitas que una CDN sirva el estado de un sitio a otro.
5. Diseñar el inicio de sesión y la autorización. Cuando se deba reconocer a la misma persona, abre una página de inicio de sesión de nivel superior y devuelve un código de autorización de un solo uso y de corta duración. Nunca coloques un token de larga duración en una URL, postMessage o una cookie no particionada.
6. Proporcionar mecanismos de fallback y observabilidad. Ejecuta en un modo sin sesión o solicita autorización explícita cuando no haya soporte; no restaures silenciosamente una cookie global de terceros. Rastrea la tasa de aciertos de cookies particionadas, el éxito de las autorizaciones y los motivos de creación o revocación de sesiones sin registrar valores de cookies ni tokens en los logs.

Respuesta de ejemplo de alta calidad

Utilizaría CHIPS para establecer el límite de preservación del estado del widget dentro de un mismo sitio de nivel superior. support.example establece una cookie con Secure, SameSite=None y Partitioned; solo almacena un identificador de sesión opaco. La sesión en el servidor vincula el tenant, el sitio de nivel superior, la expiración y la versión de revocación. Los subdominios bajo shop-a.example reutilizan una partición, mientras que shop-b.example recibe naturalmente otro estado.

La identidad entre sitios no depende de esa cookie. El widget abre una página de nivel superior para el inicio de sesión, obtiene un código de autorización de un solo uso tras la acción del usuario y lo intercambia por una sesión de corta duración en la partición actual a través de un canal de mensajes validado. Si un navegador antiguo o una política bloquea las cookies particionadas, el widget ofrece una experiencia sin sesión o una autorización explícita en lugar de recurrir a una cookie global de terceros. Prueba dos sitios de nivel superior, subdominios, cierre de sesión, expiración, pestañas concurrentes, almacenamiento en caché, CSRF, mensajes falsificados y configuraciones de privacidad. Las referencias principales son la documentación de CHIPS y Storage Access API de MDN, y la explicación de CHIPS de Privacy Sandbox.

Errores comunes

• Tratar una cookie con Partitioned como una credencial de inicio de sesión único (SSO) entre sitios, anulando el aislamiento.
• Autorizar únicamente a partir de Origin ignorando la vinculación de tenant, la revocación, CSRF y la reproducción (replay).
• Usar silenciosamente una cookie de terceros no particionada cuando CHIPS no está disponible, provocando fugas o bloqueos.
• Omitir la variación de caché en CDN, Service Worker o proxy y servir la respuesta personalizada de un sitio a otro.
• Colocar tokens de larga duración en URLs, postMessage o cookies legibles desde el frontend.

Preguntas de seguimiento y respuestas

¿Cuándo usarías CHIPS frente a la Storage Access API?

Usa CHIPS para un estado embebido independiente por sitio de nivel superior. Usa la Storage Access API cuando exista una necesidad justificada de un estado de terceros no particionado y el usuario pueda otorgar permiso, como un inicio de sesión explícito. Sus límites de privacidad difieren, por lo que una no es un sustituto silencioso de la otra.

¿Cómo demuestras que dos sitios de nivel superior no pueden compartir una sesión?

Embebe el widget en ambos sitios en el mismo navegador y registra los identificadores de sesión, las vinculaciones de tenant en el servidor y los aciertos de caché. Borrar la cookie de un sitio, cerrar sesión, abrir una nueva pestaña y cambiar de subdominio nunca debe alterar el estado del otro sitio.

¿Qué pasa si el producto insiste en reconocer a una persona a través de múltiples sitios?

Eleva el requerimiento a una autorización de identidad explícita: inicio de sesión de nivel superior, un código de un solo uso de corta duración, intercambio en el servidor y sesiones revocables. Registra el consentimiento y los fallos en lugar de crear un canal oculto de seguimiento entre sitios.