A menudo, los recursos de origen cruzado que entregan terceros no incluyen encabezados de CORP adecuados. Si se pueden solicitar sin credenciales, ahora puedes habilitar el aislamiento de origen cruzado marcándolas como tales.
Enviamos el nuevo valor de la Política de incorporaciones de origen cruzado (COEP)
credentialless
, que permite al navegador cargar recursos de origen cruzado
que no usan la Política de recursos entre dominios (CORP) mediante el envío de una solicitud
sin credenciales, como cookies. Esto ayuda a los desarrolladores a adoptar el aislamiento
de origen cruzado con mayor facilidad.
Por qué necesitamos el aislamiento de origen cruzado
Algunas APIs web aumentan el riesgo de ataques de canal lateral, como Spectre. Para mitigar ese riesgo, los navegadores ofrecen un entorno aislado basado en la habilitación que se denomina aislamiento de origen cruzado. Con un estado aislado de origen cruzado, la página web puede usar funciones con privilegios, como SharedArrayBuffer
, performance.measureUserAgentSpecificMemory()
y temporizadores de alta precisión con mejor resolución y aislar el origen de los demás, a menos que se haya aceptado.
La página web debe enviar dos encabezados HTTP para habilitar el aislamiento de origen cruzado:
Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Opener-Policy: same-origin
Con un estado aislado de origen cruzado, todos los recursos de origen cruzado deben entregarse
con CORS o configurar un encabezado Cross-Origin-Resource-Policy
para que se cargue.
Desafíos relacionados con la habilitación del aislamiento de origen cruzado
Si bien el aislamiento de origen cruzado mejora la seguridad de las páginas web y la capacidad de habilitar funciones potentes, implementarlo puede ser difícil. Uno de los desafíos más grandes es el requisito de habilitar el CORS o CORP para todos los recursos de origen cruzado. El navegador no cargará los recursos que no tengan esos encabezados en una página aislada de origen cruzado.
Por lo general, estos recursos de origen cruzado los entregan terceros para los que no es fácil agregar los encabezados necesarios.
Pero ¿qué sucede si sabemos que el recurso es lo suficientemente seguro como para cargarse? De hecho, los únicos recursos que están en riesgo son los que se solicitan con credenciales, ya que podrían incluir información sensible que el atacante no puede cargar por su cuenta. Esto significa que los recursos que se pueden solicitar sin credenciales están disponibles públicamente y son seguros para su carga.
credentialless
al rescate
Ahí es donde entra en juego COEP: credentialless
. credentialless
es un valor nuevo para el encabezado Cross-Origin-Embedder-Policy
. Al igual que require-corp
, puede habilitar el aislamiento de origen cruzado, pero, en lugar de requerir un encabezado CORP:cross-origin
para las solicitudes de origen cruzado sin cors, se envían sin credenciales (por ejemplo, cookies).
Podrás habilitar el aislamiento de origen cruzado de forma alternativa con los siguientes dos encabezados:
Cross-Origin-Embedder-Policy: credentialless
Cross-Origin-Opener-Policy: same-origin
Esto significa que el servidor de origen cruzado solicitado no podrá responder con un recurso sensible, y el solicitante siempre puede suponer que la respuesta solo contiene información disponible de forma pública.
Esto también está alineado con el plan de los navegadores de eliminar de forma gradual las cookies de terceros.
Demostración
Puedes probar varias opciones de encabezados en esta demostración: https://cross-origin-isolation.glitch.me
Preguntas frecuentes
¿Puedo enviar una solicitud con credenciales en un entorno de credentialless
?
Por supuesto, a costa de cambiar el modo de la solicitud para que se requiera una verificación de CORS en la respuesta. En el caso de las etiquetas HTML, como <audio>
, <img>
, <link>
, <script>
y <video>
, solo agrega crossorigin="use-credentials"
explícitamente para informar al navegador que envíe solicitudes con credenciales.
Por ejemplo, incluso si un documento en https://www.example.com
tiene el encabezado Cross-Origin-Embedder-Policy: credentialless
, <img
src="https://images.example.com/avatar.png" crossorigin="use-credentials">
enviará una solicitud con credenciales.
Para la API de fetch()
, se puede usar request.mode = 'cors'
.
¿Por qué COEP: require-corp
sigue siendo útil para mi sitio web con COEP: credentialless
?
COEP: require-corp
no requiere que cambies de forma manual el modo de solicitud a CORS si se necesitan cookies para algunos subrecursos de origen cruzado.
¿Puedo cargar también iframes de origen cruzado sin encabezados especiales en un entorno credentialless
?
No. La carga de iframes de origen cruzado en un entorno de credentialless
todavía requiere las mismas condiciones que require-corp
. Los documentos iframe deben proporcionarse con dos encabezados:
Cross-Origin-Embedder-Policy: credentialless
(orequire-corp
)Cross-Origin-Resource-Policy: cross-origin
La buena noticia es que hay un debate sobre cómo permitir la carga de iframes de origen cruzado sin esos encabezados asignando crossorigin="anonymous"
a los iframes.
Esto permitirá que los iframes de origen cruzado se carguen sin encabezados, pero sin
credenciales.
¿Otros navegadores adoptarán esta función?
- Problema de seguimiento de Firefox
- Solicitud de posición de Webkit: Sin indicador
- ETIQUETA W3C Solicitud de posición: Pendiente
Próximamente
Pronto habrá dos actualizaciones adicionales para mitigar otros desafíos relacionados con el aislamiento de origen cruzado:
Es posible que los usuarios que se registraron en la prueba de origen de Chrome para extender el cambio de SharedArrayBuffer debido a los obstáculos anteriores se pregunten cuándo se cerrará. Originalmente anunciamos que se rescindiría en Chrome 96, pero decidimos posponerlo hasta Chrome 106.
Recursos
- Cómo hacer que tu sitio web esté "aislado con orígenes cruzados" con COOP y COEP
- Por qué necesitas un “aislamiento de origen cruzado” para funciones potentes
- Guía para habilitar el aislamiento de origen cruzado
- Actualizaciones de SharedArrayBuffer en Android Chrome 88 y Chrome 92 para computadoras de escritorio
Foto de Martin Adams en Unsplash