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^{[Nota 1]}​. 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.^[2]​ 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.^[3]​ 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^[4]​.

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í^[5]​. 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^[6]​^[7]​. 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^[8]​ 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.^[9]​

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^[10]​. Estos datos pueden utilizarse para revelar información sobre las interacciones previas de un usuario con una aplicación web^[11]​.

•  
  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.^[12]​^[13]​ 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.^[14]​ 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^[15]​. 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^{[Nota 2]}​^[16]​.

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 HTTP[12]​^[13]​En 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^[12]​^[13]​. 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.^[15]​ 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ífica^{[Nota 3]}​Si 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^[17]​.

Las filtraciones entre sitios se conocen desde el año 2000;^[18]​ 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.^[19]​ 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.^[20]​ 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.^[21]​

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.^[22]​ 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.^[23]​^[24]​ 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.^[25]​^[26]​

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.^[22]​^[27]​^[28]​

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.^[28]​^[29]​ 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.^[28]​^[30]​ 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.^[28]​^[13]​ 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.^[31]​

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.^[32]​^[33]​

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.^[15]​ 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.^[12]​^[13]​

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.^[34]​ 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.^[35]​^[36]​

Las filtraciones entre sitios comprenden una gama muy variada de ataques^[37]​ para los que no existe una clasificación establecida y uniforme.^[38]​ Sin embargo, múltiples fuentes suelen clasificar estos ataques según las técnicas de filtración utilizadas durante un ataque.^[34]​ Hasta 2021, los investigadores han identificado más de 38 técnicas de filtración que tienen como objetivo componentes del navegador.^[32]​ 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.^[39]​ 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.^[34]​

Los ataques de sincronización se basan en la capacidad de cronometrar eventos específicos a través de múltiples respuestas.^[40]​ 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.^[20]​

Aunque inicialmente solo se utilizó para diferenciar entre el tiempo que tardaba una solicitud HTTP en resolver una respuesta,^[20]​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.^[41]​^[42]​

En 2021, Knittel et al. demostraron que la Performance API^{[Nota 4]}​ 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.^[44]​ 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.^[45]​

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.^[46]​

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.^[47]​ 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í.^[48]​^[49]​

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.^[50]​^[42]​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.^[51]​ 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.^[52]​^[53]​

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.^[54]​ 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.^[55]​^[54]​^[56]​

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. ^[54]​^[57]​^[58]​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é.^[59]​^[60]​

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.^[45]​ El ataque abusa de las limitaciones globales de los sistemas operativos o del hardware para privar de recursos compartidos.^[61]​ 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.^[62]​ Dado que este tipo de ataques normalmente también requieren canales secundarios de temporización, también se consideran ataques de temporización.^[45]​

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.^[63]​ 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^[44]​^[64]​

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.^[65]​^[66]​^[67]​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é.^[68]​

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.^[36]​

<html lang="en">
<body>
<h2>Search results</h2>
   {% for result in results %}
   <div class="result">
      <img src="//cdn.com/result-icon.png" />
      {% result.description %}
   </div>
   {% endfor %}
</body>
</html>

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).^[32]​^[69]​

Esta sencilla funcionalidad es vulnerable a un ataque de filtración cruzada, como muestra el siguiente fragmento de JavaScript.^[32]​

let icon_url = 'https://cdn.com/result-icon.png';
iframe.src = 'https://service.com/?q=password';
iframe.onload = async () => {
     const start = performance.now();
     await fetch(icon_url);
     const duration = performance.now() - start;
     if (duration < 5) // loaded resource from cache
         console.log('Query had results');
     else
         console.log('No results for query parameter');
};

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.^[36]​^[69]​^[26]​

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.^[18]​^[70]​

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.^[68]​

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.^[69]​^[72]​ 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.^[73]​ 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.^[74]​^[75]​^[76]​

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.^[77]​^[78]​ 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.^[79]​^[80]​^[81]​

Como parte de un esfuerzo por mitigar las filtraciones entre sitios web, los desarrolladores de los principales navegadores han implementado el particionamiento de almacenamiento,^[82]​ 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.^[83]​

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.^[84]​ 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.^[85]​ 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.^[86]​^[87]​

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ó. ^[88]​ Esta característica se introdujo originalmente como parte de una serie de mitigaciones contra la vulnerabilidad Spectre,^[89]​ 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.^[86]​^[90]​^[91]​

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.^{[Nota 5]}​^[91]​ 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.^[93]​ En 2020, los creadores del navegador Chrome anunciaron que activarían SameSite=Lax como estado predeterminado para las cookies en todas las plataformas.^[94]​^[95]​ 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.^[92]​ 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.^[96]​^[97]​

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.^[98]​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.^[99]​ 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.^[100]​^[75]​

• Uso compartido de recursos entre orígenes
• Política del mismo origen
• Secuencias de comandos en sitios cruzados
• Falsificación de peticiones en sitios cruzados

1. ↑ Aunque existen otras formas posibles de interacción entre navegadores y servidores web (como el protocolo WebRTC), en el contexto de las filtraciones entre sitios web, sólo las interacciones HTTP y las conexiones WebSocket se consideran importantes.^[1]​ En el resto del artículo se asumirá que las interacciones HTTP y las conexiones WebSocket son las dos únicas formas que tienen los navegadores de interactuar con los servidores web.
2. ↑ Incluye metadatos asociados a la respuesta, como códigos de estado y cabeceras HTTP^[16]​.
3. ↑ Un ejemplo de este tipo de consulta podría ser el nombre de un banco muy conocido, o la información de contacto de una persona u organización con la que se espera que el usuario haya interactuado.^[17]​
4. ↑ La API de rendimiento es un conjunto de funciones de Javascript que permiten a los sitios web recuperar varias métricas asociadas con el rendimiento web ^[43]​
5. ↑ Establecer la directiva Strict garantiza que todas las solicitudes entre sitios sean sin estado, mientras que Lax permite que el navegador envíe cookies para solicitudes que no cambian de estado (es decir, GET o HEAD) que se envían mientras se navega a una página diferente de la de origen cruzado. página.^[92]​

• Bansal, Chetan; Preibusch, Sören; Milic-Frayling, Natasa (2015). "Cache Timing Attacks Revisited: Efficient and Repeatable Browser History, OS and Network Sniffing". In Federrath, Hannes; Gollmann, Dieter (eds.). ICT Systems Security and Privacy Protection. IFIP Advances in Information and Communication Technology. Vol. 455. Springer International Publishing. pp. 97–111. doi:10.1007/978-3-319-18467-8_7. ISBN 978-3-319-18467-8. S2CID 8676881.
• Beer, Philip; Veronese, Lorenzo; Squarcina, Marco; Lindorfer, Martina (6 setiembre 2021). The Bridge between Web Applications and Mobile Platforms is Still Broken (PDF). 2023 IEEE 8th European Symposium on Security and Privacy (EuroS&P), SecWeb Workshop Proceedings. Archivado (PDF) desde el original el 7 de noviembre de 2023. Recuperado el 7 de noviembre de 2023. Las cabeceras de petición HTTP Fetch Metadata [45] son un conjunto de cabeceras HTTP que proporcionan el contexto de la petición HTTP al servidor. El servidor puede utilizar el contexto para determinar si la solicitud es maliciosa o debe permitirse.
• Bortz, Andrew; Boneh, Dan (8 May 2007). "Exposing private information by timing web applications". Proceedings of the 16th international conference on World Wide Web. WWW '07. Association for Computing Machinery. pp. 621–628. doi:10.1145/1242572.1242656. ISBN 978-1-59593-654-7. S2CID 7399871.
• Calzavara, Stefano; Roth, Sebastian; Rabitti, Alvise; Backes, Michael; Stock, Ben (2020). "A Tale of Two Headers: A Formal Analysis of Inconsistent {Click-Jacking} Protection on the Web". SEC'20: Proceedings of the 29th USENIX Conference on Security Symposium: 683–697. ISBN 978-1-939133-17-5. S2CID 214631428.
• Compagna, Luca; Jonker, Hugo; Krochewski, Johannes; Krumnow, Benjamin; Sahin, Merve (1 setiembre 2021). "A preliminary study on the adoption and effectiveness of SameSite cookies as a CSRF defence". 2021 IEEE European Symposium on Security and Privacy Workshops (EuroS&PW). IEEE. pp. 49–59. doi:10.1109/EuroSPW54576.2021.00012. ISBN 978-1-6654-1012-0. S2CID 240156960.
• Doan, Trinh Viet; van Rijswijk-Deij, Roland; Hohlfeld, Oliver; Bajpai, Vaibhav (12 febrero 2022). "An Empirical View on Consolidation of the Web". ACM Transactions on Internet Technology. 22 (3): 70:1–70:30. doi:10.1145/3503158. ISSN 1533-5399. S2CID 246803043. Aunque las recientes implementaciones de navegadores [69, 113] solucionan este problema mediante el particionamiento de caché HTTP, esta solución provoca un mayor volumen de tráfico y tiempos de carga más elevados, ya que los recursos almacenados en caché se vuelven a cargar si se solicitan en un contexto diferente.
• Somé, Dolière Francis (29 octubre 2018). Web applications security and privacy (Tesis doctoral). Université Côte d'Azur.
• Felten, Edward W.; Schneider, Michael A. (1 noviembre 2000). "Timing attacks on Web privacy". Proceedings of the 7th ACM conference on Computer and Communications Security. Association for Computing Machinery. pp. 25–32. doi:10.1145/352600.352606. ISBN 978-1-58113-203-8. S2CID 456809.
• Gelernter, Nethanel; Herzberg, Amir (12 October 2015). "Cross-Site Search Attacks". Proceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Security. CCS '15. Association for Computing Machinery. pp. 1394–1405. doi:10.1145/2810103.2813688. ISBN 978-1-4503-3832-5. S2CID 14924784.
• Jia, Yaoqi; Dong, Xinshu; Liang, Zhenkai; Saxena, Prateek (1 enero 2015). "I Know Where You've Been: Geo-Inference Attacks via the Browser Cache". IEEE Internet Computing. 19 (1): 44–53. doi:10.1109/MIC.2014.103. ISSN 1089-7801. S2CID 16087472.
• Khodayari, Soheil; Pellegrino, Giancarlo (2022). "The State of the SameSite: Studying the Usage, Effectiveness, and Adequacy of SameSite Cookies". 2022 IEEE Symposium on Security and Privacy (SP). IEEE. pp. 1590–1607. doi:10.1109/SP46214.2022.9833637. ISBN 978-1-6654-1316-9. S2CID 251140677.
• Kim, Hyungsub; Lee, Sangho; Kim, Jong (5 diciembre 2016). "Inferring browser activity and status through remote monitoring of storage usage". Proceedings of the 32nd Annual Conference on Computer Security Applications. ACSAC '16. Association for Computing Machinery. pp. 410–421. doi:10.1145/2991079.2991080. ISBN 978-1-4503-4771-6. S2CID 10483542 – via Arizona State University Library.
• Knittel, Lukas; Mainka, Christian; Niemietz, Marcus; Noß, Dominik Trevor; Schwenk, Jörg (12 noviembre 2021). "XSinator.com: From a Formal Model to the Automatic Evaluation of Cross-Site Leaks in Web Browsers". Proceedings of the 2021 ACM SIGSAC Conference on Computer and Communications Security. Association for Computing Machinery. pp. 1771–1788. doi:10.1145/3460120.3484739. ISBN 978-1-4503-8454-4. S2CID 244077807.
• Mishra, Vikas; Laperdrix, Pierre; Rudametkin, Walter; Rouvoy, Romain (2021). "Déjà vu: Abusing Browser Cache Headers to Identify and Track Online Users". Proceedings on Privacy Enhancing Technologies. 2021 (2): 391–406. doi:10.2478/popets-2021-0033. hdl:20.500.12210/57495. ISSN 2299-0984. S2CID 231779262. Archivado desde el original el 29 de octubre de 2023. Recuperado el 29 de octubre de 2023.
• Rautenstrauch, Jannis; Pellegrino, Giancarlo; Stock, Ben (21 mayo 2023). "The Leaky Web: Automated Discovery of Cross-Site Information Leaks in Browsers and the Web". 2023 IEEE Symposium on Security and Privacy (SP). IEEE. pp. 2744–2760. doi:10.1109/SP46215.2023.10179311. ISBN 978-1-6654-9336-9. S2CID 259321089 – via CISPA – Helmholtz Center for Information Security Publication Database.
• Reis, Charles; Moshchuk, Alexander; Oskov, Nasko (2019). "Site Isolation: Process Separation for Web Sites within the Browser". SEC'19: Proceedings of the 28th USENIX Conference on Security Symposium. USENIX Association. pp. 1661–1678. ISBN 978-1-939133-06-9. S2CID 199522067. Archivado desde el original el 7 de noviembre de 2023. Recuperado el 7 de noviembre de 2023.
• Schwenk, Jörg; Niemietz, Marcus; Mainka, Christian (2017). {Same-Origin} Policy: Evaluation in Modern Browsers. USENIX Association. pp. 713–727. ISBN 978-1-931971-40-9. S2CID 9641053.
• Snyder, Peter; Karami, Soroush; Edelstein, Arthur; Livshits, Benjamin; Haddadi, Hamed (26 octubre 2023). "Pool-party: exploiting browser resource pools for web tracking". Proceedings of the 32nd USENIX Conference on Security Symposium. SEC '23. USENIX Association: 7091–7105. ISBN 978-1-939133-37-3.
• Staicu, Cristian-Alexandru; Pradel, Michael (2019). "Leaky Images: Targeted Privacy Attacks in the Web". Proceedings of the 28th USENIX Conference on Security Symposium. SEC '19: 923–939. ISBN 978-1-939133-06-9. S2CID 156052170.
• Sudhodanan, Avinash; Khodayari, Soheil; Caballero, Juan (2020). "Cross-Origin State Inference (COSI) Attacks: Leaking Web Site States through XS-Leaks". Proceedings 2020 Network and Distributed System Security Symposium. Internet Society. doi:10.14722/ndss.2020.24278. ISBN 978-1-891562-61-7. S2CID 199452779.
• Van Goethem, Tom; Franken, Gertjan; Sanchez-Rola, Iskander; Dworken, David; Joosen, Wouter (6 setiembre 2021). Understanding Cross-site Leaks and Defenses (PDF). 2023 IEEE 8th European Symposium on Security and Privacy (EuroS&P), SecWeb Workshop Proceedings. p. 1. Archivado (PDF) desde el original el 11 de octubre de 2023. Recuperado el 11 de octubre de 2023.
• Van Goethem, Tom; Franken, Gertjan; Sanchez-Rola, Iskander; Dworken, David; Joosen, Wouter (30 May 2022). "SoK: Exploring Current and Future Research Directions on XS-Leaks through an Extended Formal Model". Proceedings of the 2022 ACM on Asia Conference on Computer and Communications Security. Association for Computing Machinery. pp. 784–798. doi:10.1145/3488932.3517416. ISBN 978-1-4503-9140-5. S2CID 248990284. Este artículo incorpora texto de Tom Van Goethem, Gertjan Franken, Iskander Sanchez-Rola, David Dworken y Wouter Joosen disponible bajo licencia CC BY 4.0.
• Van Goethem, Tom; Sanchez-Rola, Iskander; Joosen, Wouter (2023). "Scripted Henchmen: Leveraging XS-Leaks for Cross-Site Vulnerability Detection". 2023 IEEE Security and Privacy Workshops (SPW). IEEE. pp. 371–383. doi:10.1109/SPW59333.2023.00038. ISBN 979-8-3503-1236-2. S2CID 259267534. Recuperado el 7 de noviembre de 2023.
• Van Goethem, Tom; Vanhoef, Mathy; Piessens, Frank; Joosen, Wouter (2016). Request and Conquer: Exposing {Cross-Origin} Resource Size. pp. 447–462. ISBN 978-1-931971-32-4.
• Van Goethem, Tom; Joosen, Wouter; Nikiforakis, Nick (12 October 2015). "The Clock is Still Ticking: Timing Attacks in the Modern Web". Proceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Security. CCS '15. Association for Computing Machinery. pp. 1382–1393. doi:10.1145/2810103.2813632. ISBN 978-1-4503-3832-5. S2CID 17705638.
• Vila, Pepe; Köpf, Boris (2017). "Loophole: Timing Attacks on Shared Event Loops in Chrome". SEC'17: Proceedings of the 26th USENIX Conference on Security Symposium: 849–864. arXiv:1702.06764. ISBN 978-1-931971-40-9.
• Zaheri, Mojtaba; Curtmola, Reza (2021). "Leakuidator: Leaky Resource Attacks and Countermeasures". In Garcia-Alfaro, Joaquin; Li, Shujun; Poovendran, Radha; Debar, Hervé; Yung, Moti (eds.). Security and Privacy in Communication Networks. Lecture Notes of the Institute for Computer Sciences, Social Informatics and Telecommunications Engineering. Vol. 399. Springer International Publishing. pp. 143–163. doi:10.1007/978-3-030-90022-9_8. ISBN 978-3-030-90022-9. S2CID 237476137.
• Zaheri, Mojtaba; Oren, Yossi; Curtmola, Reza (2022). "Targeted Deanonymization via the Cache Side Channel: Attacks and Defenses". Proceedings of the 31th USENIX Conference on Security Symposium. SEC '22: 1505–1523. ISBN 978-1-939133-31-1. S2CID 251092191.
• Zalewski, Michal (15 noviembre 2011). The Tangled Web: A Guide to Securing Modern Web Applications. No Starch Press. ISBN 978-1-59327-388-0.

• Knittel, Lukas; Mainka, Christian; Niemietz, Marcus; Noß, Dominik Trevor; Schwenk, Jörg (12 noviembre 2021). "XSinator.com: From a Formal Model to the Automatic Evaluation of Cross-Site Leaks in Web Browsers". Proceedings of the 2021 ACM SIGSAC Conference on Computer and Communications Security. Association for Computing Machinery. pp. 1771–1788. doi:10.1145/3460120.3484739. ISBN 978-1-4503-8454-4. S2CID 244077807.
• Rautenstrauch, Jannis; Pellegrino, Giancarlo; Stock, Ben (21 mayo 2023). "The Leaky Web: Automated Discovery of Cross-Site Information Leaks in Browsers and the Web". 2023 IEEE Symposium on Security and Privacy (SP). IEEE. pp. 2744–2760. doi:10.1109/SP46215.2023.10179311. ISBN 978-1-6654-9336-9. S2CID 259321089 – via CISPA – Helmholtz Center for Information Security Publication Database.
• Van Goethem, Tom; Franken, Gertjan; Sanchez-Rola, Iskander; Dworken, David; Joosen, Wouter (30 mayo 2022). "SoK: Exploring Current and Future Research Directions on XS-Leaks through an Extended Formal Model". Proceedings of the 2022 ACM on Asia Conference on Computer and Communications Security. Association for Computing Machinery. pp. 784–798. doi:10.1145/3488932.3517416. ISBN 978-1-4503-9140-5. S2CID 248990284.
• Van Goethem, Tom; Franken, Gertjan; Sanchez-Rola, Iskander; Dworken, David; Joosen, Wouter (6 setiembre 2021). Understanding Cross-site Leaks and Defenses (PDF). 2023 IEEE 8th European Symposium on Security and Privacy (EuroS&P), SecWeb Workshop Proceedings. p. 1. Archivado (PDF) desde el original el 11 de octubre de 2023. Recuperado el 11 de octubre de 2023.

• "XSLeaks Wiki - Introducción". xsleaks.dev.
• "XSinator - XS-Leak Browser Test Suite". xsinator.com.