# Cross-site leaks

Cross-site leaks, también conocido como XS-leaks, es un término de seguridad en Internet utilizado para describir una clase de ataques utilizados para acceder a la información sensible de un usuario en otro sitio web. Las fugas entre sitios permiten a un atacante acceder a las interacciones de un usuario con otros sitios web. Esto puede contener información sensible. Normalmente, los navegadores impiden que otros sitios web vean esta información. Esto se hace mediante un conjunto de reglas denominadas política del mismo origen. A veces, los atacantes pueden eludir estas normas mediante una "filtración entre sitios". Los ataques que utilizan una filtración entre sitios suelen iniciarse incitando a los usuarios a visitar el sitio web del atacante. Tras la visita, el atacante utiliza código malicioso en su sitio web para interactuar con otro sitio web. Esto puede ser utilizado por un atacante para conocer las acciones previas del usuario en el otro sitio web. La información de este ataque puede identificar de forma exclusiva al usuario para el atacante.
Estos ataques están documentados desde el año 2000. Uno de los primeros trabajos de investigación sobre el tema fue publicado por investigadores de la Universidad de Purdue. En él se describía un ataque en el que se explotaba la caché web para recopilar información sobre un sitio web. Desde entonces, las filtraciones entre sitios se han vuelto cada vez más sofisticadas. Los investigadores han descubierto nuevas filtraciones dirigidas a varios componentes del navegador web. Aunque la eficacia de algunas de estas técnicas varía, se descubren continuamente otras nuevas.Algunos métodos antiguos se bloquean mediante actualizaciones de los navegadores. La introducción y supresión de funciones en Internet también hace que algunos ataques pierdan eficacia.
Las filtraciones entre sitios son una forma diversa de ataque, y no existe una clasificación coherente de este tipo de ataques. Múltiples fuentes clasifican las filtraciones entre sitios según la técnica utilizada para filtrar la información. Entre las más conocidas se encuentran los ataques de sincronización, que dependen de eventos de sincronización dentro del navegador web. Los eventos de error constituyen otra categoría, utilizando la presencia o ausencia de eventos para revelar datos. Además, los ataques de temporización de caché se basan en la caché web para desvelar información. Desde 2023, también se han descubierto ataques más recientes que utilizan los sistemas operativos y los límites del navegador web para filtrar información.
Antes de 2017, la defensa contra las filtraciones entre sitios web se consideraba difícil. Esto se debía a que muchos de los problemas de fuga de información explotados por los ataques de fuga entre sitios eran inherentes a la forma en que funcionaban los sitios web. La mayoría de las defensas contra este tipo de ataques se han introducido después de 2017 en forma de extensiones del protocolo de transferencia de hipertexto (HTTP). Estas extensiones permiten a los sitios web indicar al navegador que no permita o anote determinados tipos de solicitudes de estado procedentes de otros sitios web. Uno de los enfoques más exitosos que han implementado los navegadores son las cookies SameSite.Las cookies SameSite permiten a los sitios web establecer una directiva que impide a otros sitios web acceder a las cookies sensibles y enviarlas. Otra defensa consiste en utilizar cabeceras HTTP para restringir qué sitios web pueden incrustar un sitio concreto. La partición de la caché también sirve como defensa contra las filtraciones entre sitios, impidiendo que otros sitios web utilicen la caché web para exfiltrar datos.

## Antecedentes

Las aplicaciones web tienen dos componentes principales: un navegador y uno o varios servidores web. El navegador suele interactuar con los servidores a través del protocolo de transferencia de hipertexto (HTTP) y conexiones WebSocket para ofrecer una aplicación web. Para que la aplicación web sea interactiva, el navegador también renderiza HTML y CSS, y ejecuta código JavaScript proporcionado por la aplicación web. A menudo, los usuarios interactúan con la aplicación web durante largos periodos de tiempo, realizando múltiples peticiones al servidor. Para hacer un seguimiento de estas peticiones, las aplicaciones web suelen utilizar un identificador persistente vinculado a un usuario concreto a través de su sesión actual o cuenta de usuario. Este identificador puede incluir detalles como la edad o el nivel de acceso, que reflejan el historial del usuario con la aplicación web. Si se revelan a otros sitios web, estos atributos identificables podrían desanonimizar al usuario.
Idealmente, cada aplicación web debería funcionar de forma independiente sin interferir con las demás. Sin embargo, debido a varias decisiones de diseño tomadas durante los primeros años de la web, las aplicaciones web pueden interactuar regularmente entre sí. Para evitar el abuso de este comportamiento, los navegadores web aplican un conjunto de reglas llamado política del mismo origen que limita las interacciones directas entre aplicaciones web de distintas fuentes. A pesar de estas restricciones, las aplicaciones web a menudo necesitan cargar contenido de fuentes externas, como instrucciones para mostrar elementos en una página, diseños y vídeos o imágenes. Este tipo de interacciones, denominadas peticiones de origen cruzado, son excepciones a la política del mismo origen y se rigen por un conjunto de normas estrictas conocidas como marco de uso compartido de recursos de origen cruzado (CORS). CORS garantiza que estas interacciones se produzcan en condiciones controladas, impidiendo el acceso no autorizado a datos que una aplicación web no puede ver. Esto se consigue exigiendo un permiso explícito antes de que otros sitios web puedan acceder al contenido de estas peticiones.
Las fugas entre sitios permiten a los atacantes eludir las restricciones impuestas por la política del mismo origen y el marco CORS. Aprovechan los problemas de fuga de información (canales laterales) que históricamente han estado presentes en los navegadores. Utilizando estos canales laterales, un atacante puede ejecutar código capaz de deducir detalles sobre datos que la política del mismo origen habría protegido. Estos datos pueden utilizarse para revelar información sobre las interacciones previas de un usuario con una aplicación web.

## Mecanismo

* En ausencia de terceros, el navegador del usuario envía al servidor web una petición HTTP. El servidor envía una respuesta que depende de la naturaleza de la solicitud.
* Un atacante identifica una URL vulnerable y envía al usuario a su sitio web a través de un correo electrónico. Cuando el usuario accede al sitio web del atacante, éste puede realizar peticiones maliciosas al servidor web utilizando la URL vulnerable.
* Se impide al atacante leer la respuesta del servidor web. Sin embargo, otros factores como el tiempo de respuesta o el tamaño pueden ser medidos por el atacante, filtrando información sobre la respuesta - un ataque de canal lateral.
Para llevar a cabo un ataque de filtración entre sitios, un atacante debe estudiar primero cómo interactúa un sitio web con los usuarios. Por ejemplo, si el atacante está tratando de atacar Gmail, podría tratar de encontrar una URL de búsqueda que devuelva una respuesta HTTP diferente basada en cuántos resultados de búsqueda se encuentran para un término de búsqueda específico en los correos electrónicos de un usuario. Una vez que un atacante encuentra una URL específica, puede alojar un sitio web y hacer phishing o atraer a usuarios desprevenidos al sitio web. Una vez que la víctima se encuentra en el sitio web del atacante, éste puede utilizar varias técnicas de incrustación para iniciar peticiones HTTP de origen cruzado a la URL identificada por el atacante. Sin embargo, dado que el atacante se encuentra en un sitio web diferente, la política del mismo origen impuesta por el navegador web impedirá que el atacante lea directamente cualquier parte de la respuesta enviada por el sitio web vulnerable.
Para sortear esta barrera de seguridad, el atacante puede utilizar métodos de filtración del navegador, para distinguir diferencias sutiles entre diferentes respuestas. Los métodos de fuga del navegador son fragmentos de JavaScript, CSS o HTML que aprovechan los problemas de fuga de información (canales secundarios) que existen desde hace tiempo en el navegador web para revelar características específicas sobre una respuesta HTTPEn el caso de Gmail, el atacante podría utilizar JavaScript para cronometrar el tiempo que tarda el navegador en analizar la respuesta HTTP devuelta por el resultado de la búsqueda. Si el tiempo empleado en analizar la respuesta devuelta por el endpoint era bajo, el atacante podía deducir que no había resultados de búsqueda para su consulta. Alternativamente, si el sitio tardó más, el atacante podría inferir que se devolvieron múltiples resultados de búsqueda. El atacante puede utilizar posteriormente la información obtenida a través de estas fugas de información para exfiltrar información sensible, que puede ser utilizada para rastrear y desanonimizar a la víctima. En el caso de Gmail, el atacante podría realizar una solicitud al punto final de búsqueda con una consulta y posteriormente medir el tiempo que tardó la consulta para averiguar si el usuario tenía o no algún correo electrónico que contuviera una cadena de consulta específicaSi una respuesta tarda muy poco tiempo en procesarse, el atacante puede asumir que no se devolvió ningún resultado de búsqueda.Por el contrario, si una respuesta tarda una gran cantidad de tiempo en procesarse, el atacante deduce que se han devuelto muchos resultados de búsqueda. Al realizar múltiples peticiones, un atacante podría obtener información significativa sobre el estado actual de la aplicación víctima, revelando potencialmente información privada de un usuario, lo que ayudaría a lanzar sofisticados ataques de spam y phishing.

## Historia

Las filtraciones entre sitios se conocen desde el año 2000; los artículos de investigación de ese año de la Universidad de Purdue describen un ataque teórico que utiliza la caché HTTP para comprometer la privacidad de los hábitos de navegación de un usuario. En 2007, Andrew Bortz y Dan Boneh de la Universidad de Stanford publicaron un libro blanco en el que detallaban un ataque que utilizaba información de tiempo para determinar el tamaño de las respuestas entre sitios. En 2015, investigadores de la Universidad de Bar-Ilan describieron un ataque de búsqueda entre sitios que utilizaba métodos de filtración similares. El ataque empleaba una técnica en la que la entrada se manipulaba para aumentar el tamaño de las respuestas, lo que provocaba un aumento proporcional del tiempo necesario para generar las respuestas, incrementando así la precisión del ataque.
Investigadores de seguridad independientes han publicado entradas de blog que describen ataques de fuga entre sitios contra aplicaciones del mundo real. En 2009, Chris Evans describió un ataque contra Yahoo Mail a través del cual un sitio malicioso podía buscar información sensible en la bandeja de entrada de un usuario. En 2018, Luan Herrara encontró una vulnerabilidad de fuga entre sitios en el rastreador de errores Monorail de Google, utilizado por proyectos como Chromium, Angle y Skia Graphics Engine. Este exploit permitió a Herrara exfiltrar datos sobre problemas de seguridad sensibles abusando del punto final de búsqueda del rastreador de errores. En 2019, Terjanq, un investigador de seguridad polaco, publicó una entrada de blog que describía un ataque de búsqueda entre sitios que les permitió exfiltrar información sensible del usuario a través de productos de alto perfil de Google.
Como parte de su creciente atención a la resolución de problemas de seguridad que dependen del uso indebido de antiguas funciones de la plataforma web, Google lanzó XSLeaks Wiki en 2020. El objetivo de esta iniciativa era crear una base de datos de conocimiento abierto sobre funciones de plataformas web que se estaban utilizando de forma indebida, así como analizar y recopilar información sobre ataques de filtración entre sitios.
Desde 2020, ha habido cierto interés entre la comunidad académica de seguridad por normalizar la clasificación de estos ataques. En 2020, Sudhodanan et al. fueron de los primeros en resumir sistemáticamente trabajos anteriores sobre filtraciones entre sitios y desarrollaron una herramienta llamada BASTA-COSI que podía utilizarse para detectar URL con filtraciones. En 2021, Knittel et al. propusieron un nuevo modelo formal para evaluar y caracterizar las filtraciones entre sitios, lo que permitió a los investigadores encontrar nuevas filtraciones que afectaban a varios navegadores. En 2022, Van Goethem et al. evaluaron las defensas disponibles actualmente contra estos ataques y ampliaron el modelo existente para considerar el estado de los componentes del navegador como parte del modelo. En 2023, un artículo publicado por Rautenstrauch et al. en el que se sistematizaban las investigaciones anteriores sobre las filtraciones entre sitios fue galardonado con el Distinguished Paper Award en el Simposio sobre Seguridad y Privacidad del IEEE.

## Modelo de amenaza

El modelo de amenaza de una filtración entre sitios se basa en que el atacante sea capaz de dirigir a la víctima a un sitio web malicioso que esté, al menos parcialmente, bajo su control. El atacante puede lograr esto comprometiendo una página web, suplantando al usuario hacia una página web y cargando código arbitrario, o utilizando un anuncio malicioso en una página web que de otro modo sería segura.
Los ataques de filtración entre sitios requieren que el atacante identifique al menos una URL dependiente del estado en la aplicación víctima para utilizarla en la aplicación atacada. Dependiendo del estado de la aplicación víctima, esta URL debe proporcionar al menos dos respuestas. Se puede crear una URL, por ejemplo, enlazando a un contenido al que el usuario sólo puede acceder si ha iniciado sesión en el sitio web objetivo. Si se incluye esta URL dependiente del estado en la aplicación maliciosa, se iniciará una solicitud de origen cruzado a la aplicación de destino. Dado que se trata de una solicitud de origen cruzado, la política del mismo origen impide al atacante leer el contenido de la respuesta. Sin embargo, utilizando un método de filtración del navegador, el atacante puede consultar características identificables específicas de la respuesta, como el código de estado HTTP. Esto permite al atacante distinguir entre las respuestas y obtener información sobre el estado de la aplicación víctima.
Aunque todos los métodos para iniciar una petición cross-origin a una URL en una página web pueden combinarse con todos los métodos de filtración del navegador, esto no funciona en la práctica porque existen dependencias entre los diferentes métodos de inclusión y las filtraciones del navegador. Por ejemplo, si el método de filtración del navegador se basa en la comprobación de atributos CSS como la anchura y la altura de un elemento, la técnica de inclusión debe utilizar un elemento HTML con una propiedad de anchura y altura, como un elemento de imagen, que cambie cuando una solicitud de origen cruzado devuelva una imagen no válida o con un tamaño diferente.

## Tipos

Las filtraciones entre sitios comprenden una gama muy variada de ataques para los que no existe una clasificación establecida y uniforme. Sin embargo, múltiples fuentes suelen clasificar estos ataques según las técnicas de filtración utilizadas durante un ataque. Hasta 2021, los investigadores han identificado más de 38 técnicas de filtración que tienen como objetivo componentes del navegador. Normalmente se descubren nuevas técnicas debido a cambios en las API de la plataforma web, que son interfaces de JavaScript que permiten a los sitios web consultar el navegador para obtener información específica. Aunque la mayoría de estas técnicas implican la detección directa de cambios de estado en la aplicación web víctima, algunos ataques también explotan alteraciones en componentes compartidos dentro del navegador para obtener indirectamente información sobre la aplicación web víctima.

### Ataques de sincronización

Los ataques de sincronización se basan en la capacidad de cronometrar eventos específicos a través de múltiples respuestas. Fueron descubiertos por investigadores de la Universidad de Stanford en 2007, lo que los convierte en uno de los tipos más antiguos de ataques de filtración entre sitios.
Aunque inicialmente solo se utilizó para diferenciar entre el tiempo que tardaba una solicitud HTTP en resolver una respuesta,las investigaciones realizadas después de 2007 han demostrado el uso de esta técnica de filtración para detectar otras diferencias entre estados de aplicaciones web. En 2017, Vila et al. demostraron que los ataques de temporización podían inferir tiempos de ejecución entre orígenes a través de contextos integrados. Esto fue posible gracias a la falta de funciones de aislamiento de sitios en los navegadores contemporáneos, lo que permitió que un sitio web atacante ralentizara y amplificara las diferencias de temporización causadas por las diferencias en la cantidad de JavaScript que se ejecutaba cuando se enviaban eventos a una aplicación web víctima.
En 2021, Knittel et al. demostraron que la Performance API podía filtrar la presencia o ausencia de redirecciones en las respuestas. Esto era posible debido a un error en la Performance API que permitía que la cantidad de tiempo mostrada al usuario fuera negativa cuando se producía una redirección. Posteriormente, Google Chrome corrigió este error. En 2023, Snyder et al. demostraron que los ataques de temporización podían utilizarse para realizar ataques pool-party en los que los sitios web podían bloquear recursos compartidos agotando su cuota global. Al hacer que la aplicación web víctima ejecutara JavaScript que utilizaba estos recursos compartidos y, a continuación, cronometrar cuánto tardaban estas ejecuciones, los investigadores pudieron revelar información sobre el estado de una aplicación web.

### Eventos de error

Los eventos de error son una técnica de filtración que permite a un atacante distinguir entre múltiples respuestas registrando manejadores de eventos de error y escuchando eventos a través de ellos. Debido a su versatilidad y capacidad para filtrar una amplia gama de información, los eventos de error se consideran un vector clásico de filtración entre sitios.
Uno de los casos más comunes de uso de eventos de error en ataques de filtración entre sitios es determinar las respuestas HTTP adjuntando los manejadores de eventos onload y onerror a un elemento HTML y esperando a que ocurran eventos de error específicos. La ausencia de eventos de error indica que no se han producido errores HTTP. Por el contrario, si el manejador onerror se activa con un evento de error específico, el atacante puede utilizar esa información para distinguir entre tipos de contenido HTTP, códigos de estado y errores de tipo multimedia. En 2019, investigadores de TU Darmstadt demostraron que esta técnica podría utilizarse para realizar un ataque de desanonimización dirigido contra usuarios de servicios web populares como Dropbox, Google Docs y GitHub que permiten a los usuarios compartir contenido arbitrario entre sí.
Desde 2019, se han ampliado las capacidades de los eventos de error. En 2020, Janc et al. demostraron que al establecer el modo de redirección para una solicitud de obtención en manual, un sitio web podría filtrar información sobre si una URL específica es una redirección.Al mismo tiempo, Jon Masas y Luan Herrara demostraron que al abusar de los límites relacionados con URL, un atacante podría desencadenar eventos de error que podrían utilizarse para filtrar información de redirección sobre URL. En 2021, Knittel et al. demostraron que los eventos de error generados por una comprobación de integridad de sub-recursos, un mecanismo que se utiliza para confirmar que un sub-recurso cargado en un sitio web no ha sido cambiado o comprometido, también podría ser utilizado para adivinar el contenido en bruto de una respuesta HTTP y filtrar la longitud del contenido de la respuesta.

### Ataques de sincronización de caché

Los ataques de sincronización de caché se basan en la capacidad de inferir aciertos y errores en las cachés compartidas de la plataforma web. Uno de los primeros casos de ataque de sincronización de caché consistió en realizar una solicitud de origen cruzado a una página y, a continuación, sondear la existencia de los recursos cargados por la solicitud en la caché compartida HTTP y DNS. El documento que describe el ataque fue escrito por investigadores de la Universidad de Purdue en 2000, y describe la capacidad del ataque para filtrar una gran parte del historial de navegación de un usuario mediante la comprobación selectiva de si los recursos que son exclusivos de una página web se han cargado.
Este ataque se ha vuelto cada vez más sofisticado, permitiendo la filtración de otro tipo de información. En 2014, Jia et al. demostraron que este ataque podía geolocalizar a una persona midiendo el tiempo que tarda en cargarse el dominio localizado de un grupo de sitios web multinacionales.En 2015, Van Goethem et al. demostraron que utilizando la entonces recién introducida caché de aplicaciones, un sitio web podía ordenar al navegador que ignorara y anulara cualquier directiva de caché que enviara el sitio web víctima. El documento también demostró que un sitio web podía obtener información sobre el tamaño de la respuesta almacenada en caché cronometrando el acceso a la caché.

### Límites globales

Los límites globales, también conocidos como ataques pool-party, no dependen directamente del estado de la aplicación web víctima. Esta filtración entre sitios fue descubierta por primera vez por Knittel et al. en 2020 y ampliada por Snyder et al. en 2023. El ataque abusa de las limitaciones globales de los sistemas operativos o del hardware para privar de recursos compartidos. Entre los límites globales de los que se puede abusar se incluyen el número de conexiones de socket sin procesar que se pueden registrar y el número de trabajadores de servicio que se pueden registrar. Un atacante puede inferir el estado del sitio web víctima realizando una actividad que active estos límites globales y comparando cualquier diferencia en el comportamiento del navegador cuando se realiza la misma actividad sin que el sitio web víctima esté cargado. Dado que este tipo de ataques normalmente también requieren canales secundarios de temporización, también se consideran ataques de temporización.

### Otras técnicas

En 2019, Gareth Heyes descubrió que estableciendo el hash de la URL de un sitio web en un valor específico y detectando posteriormente si se producía una pérdida de foco en la página web actual, un atacante podía determinar la presencia y posición de elementos en un sitio web víctima. En 2020, Knittel et al. demostraron que un atacante podía filtrar si se había establecido o no un encabezado Cross-Origin-Opener-Policy obteniendo una referencia al objeto ventana de un sitio web víctima mediante el enmarcado del sitio web o la creación de una ventana emergente del sitio web víctima. Utilizando la misma técnica de obtención de referencias a ventanas, un atacante también podía contar el número de marcos que tenía un sitio web víctima a través de la propiedad window.length
Aunque se siguen encontrando nuevas técnicas, las técnicas más antiguas para realizar filtraciones entre sitios han quedado obsoletas debido a los cambios en las especificaciones del World Wide Web Consortium (W3C) y a las actualizaciones de los navegadores. En diciembre de 2020, Apple actualizó el mecanismo de prevención de rastreo inteligente (ITP) de su navegador Safari, dejando sin efecto una serie de técnicas de filtración entre sitios que los investigadores de Google habían descubierto.Asimismo, la introducción generalizada de la partición de caché en los principales navegadores en 2020 ha reducido la potencia de los ataques de sincronización de caché.

## Ejemplo

El ejemplo de una aplicación web basada en Python con una interfaz de punto final de búsqueda implementada utilizando la siguiente plantilla Jinja demuestra un escenario común de cómo podría ocurrir un ataque de filtración entre sitios.
Este código es una plantilla para mostrar resultados de búsqueda en una página web. Recorre una colección de resultados proporcionados por un servidor HTTP y muestra cada resultado junto con su descripción dentro de un elemento div estructurado junto a un icono cargado desde un sitio web diferente. La aplicación subyacente autentica al usuario basándose en las cookies que se adjuntan a la solicitud y realiza una búsqueda textual de la información privada del usuario utilizando una cadena proporcionada en un parámetro GET. Por cada resultado devuelto, se muestra junto a él un icono cargado desde una red de distribución de contenidos (CDN).
Esta sencilla funcionalidad es vulnerable a un ataque de filtración cruzada, como muestra el siguiente fragmento de JavaScript.
Este fragmento de JavaScript, que puede incrustarse en una aplicación web controlada por el atacante, carga la aplicación web víctima dentro de un iframe, espera a que se cargue el documento y posteriormente solicita el icono a la CDN. El atacante puede determinar si el icono fue almacenado en caché cronometrando su retorno. Dado que el icono sólo se almacena en caché si la aplicación víctima devuelve al menos un resultado, el atacante puede determinar si la aplicación víctima ha devuelto algún resultado para la consulta en cuestión.

## Defensas

Antes de 2017, los sitios web podían defenderse de las filtraciones entre sitios asegurándose de que se devolvía la misma respuesta para todos los estados de la aplicación, frustrando la capacidad del atacante para diferenciar las solicitudes. Este enfoque era inviable para cualquier sitio web no trivial. El segundo enfoque consistía en crear URL específicas de sesión que no funcionaran fuera de la sesión de un usuario. Este enfoque limitaba el uso compartido de enlaces y era poco práctico.
La mayoría de las defensas modernas son extensiones del protocolo HTTP que impiden los cambios de estado, hacen que las peticiones entre orígenes sean apátridas o aíslan completamente los recursos compartidos entre múltiples orígenes.

### Aislar los recursos compartidos

Uno de los primeros métodos para realizar filtraciones entre sitios fue el uso de la caché HTTP, un enfoque que se basaba en la consulta de la caché del navegador en busca de recursos únicos que el sitio web de la víctima pudiera haber cargado. Midiendo el tiempo que tardaba una solicitud de origen cruzado en resolver un sitio web atacante, se podía determinar si el recurso estaba almacenado en caché y, en caso afirmativo, el estado de la aplicación víctima. Desde octubre de 2020, la mayoría de los navegadores han implementado la partición de caché HTTP, lo que reduce drásticamente la eficacia de este método. La partición de caché HTTP funciona aplicando múltiples claves a cada solicitud almacenada en caché en función del sitio web que solicitó el recurso. Esto significa que si un sitio web carga y almacena en caché un recurso, la solicitud almacenada en caché está vinculada a una clave única generada a partir de la URL del recurso y la del sitio web solicitante. Si otro sitio web intenta acceder al mismo recurso, la solicitud se tratará como un fallo de caché a menos que ese sitio web haya almacenado previamente en caché una solicitud idéntica. Esto impide que un sitio web atacante deduzca si un recurso ha sido almacenado en caché por un sitio web víctima.
Otra característica, más orientada al desarrollador, que permite el aislamiento de contextos de ejecución incluye la cabecera Cross-Origin-Opener-Policy (COOP), que se añadió originalmente para abordar los problemas de Spectre en el navegador. Ha demostrado ser útil para evitar filtraciones entre sitios web, ya que si el encabezado se establece con una directiva de mismo origen como parte de la respuesta, el navegador no permitirá que los sitios web de origen cruzado puedan mantener una referencia al sitio web defensor cuando se abra desde una página de terceros.
Como parte de un esfuerzo por mitigar las filtraciones entre sitios web, los desarrolladores de los principales navegadores han implementado el particionamiento de almacenamiento, lo que permite que todos los recursos compartidos utilizados por cada sitio web tengan varias claves, reduciendo drásticamente el número de técnicas de inclusión que pueden inferir los estados de una aplicación web.

### Prevención de cambios de estado

Los ataques cross-site leak dependen de la capacidad de una página web maliciosa para recibir respuestas cross-origin de la aplicación víctima. Al impedir que la aplicación maliciosa pueda recibir respuestas de origen cruzado, el usuario ya no corre el riesgo de que se filtren cambios de estado. Este enfoque se observa en defensas como el encabezado obsoleto X-Frame-Options y la directiva más reciente frame-ancestors en los encabezados Content-Security Policy, que permiten a la aplicación víctima especificar qué sitios web pueden incluirla como marco incrustado. Si la aplicación víctima desautoriza la incrustación del sitio web en contextos no fiables, la aplicación maliciosa ya no podrá observar la respuesta a las solicitudes de origen cruzado realizadas a la aplicación víctima utilizando la técnica de marco incrustado.
Un enfoque similar adoptan el mecanismo de bloqueo de recursos de origen cruzado (CORB) y el encabezado de política de recursos de origen cruzado (CORP), que permite que una solicitud de origen cruzado tenga éxito pero bloquea la carga del contenido en sitios web de terceros si hay una discordancia entre el tipo de contenido que se esperaba y el que se recibió. Esta característica se introdujo originalmente como parte de una serie de mitigaciones contra la vulnerabilidad Spectre, pero ha demostrado ser útil para evitar filtraciones de origen cruzado, ya que bloquea la página web maliciosa para que no reciba la respuesta y pueda inferir cambios de estado.

### Hacer que las peticiones de origen cruzado no tengan estado

Uno de los enfoques más efectivos para mitigar las filtraciones entre sitios ha sido el uso del parámetro SameSite en las cookies. Una vez configurado como Lax o Strict, este parámetro evita que el navegador envíe cookies en la mayoría de las solicitudes de terceros, haciendo que la solicitud sea apátrida. La adopción de las cookies Same-Site, sin embargo, ha sido lenta porque requiere cambios en la forma en que operan muchos servidores web especializados, como los proveedores de autenticación. En 2020, los creadores del navegador Chrome anunciaron que activarían SameSite=Lax como estado predeterminado para las cookies en todas las plataformas. A pesar de esto, todavía hay casos en los que no se respetan las cookies SameSite=Lax, como la mitigación LAX+POST de Chrome, que permite que un sitio de origen cruzado utilice una cookie SameSite=Lax en una solicitud si y solo si la solicitud se envía mientras se navega por la página y se produce en los dos minutos siguientes a la configuración de la cookie. Esto ha dado lugar a desvíos y soluciones contra la limitación SameSite=Lax que todavía permiten que se produzcan filtraciones entre sitios.
Las cabeceras de metadatos Fetch, que incluyen las cabeceras Sec-Fetch-Site, Sec-Fetch-Mode, Sec-Fetch-User y Sec-Fetch-Dest, que proporcionan información sobre el dominio que inició la solicitud, detalles sobre el inicio de la solicitud y el destino de la solicitud, respectivamente, al servidor web defensor, también se han utilizado para mitigar los ataques de filtración entre sitios.Estas cabeceras permiten al servidor web distinguir entre solicitudes legítimas de terceros en el mismo sitio y solicitudes dañinas de origen cruzado. Al discriminar entre estas peticiones, el servidor puede enviar una respuesta sin estado a las peticiones maliciosas de terceros y una respuesta con estado a las peticiones rutinarias del mismo sitio. Para evitar el uso abusivo de estas cabeceras, no se permite que una aplicación web configure estas cabeceras, que sólo deben ser configuradas por el navegador.