Carga recursos de origen cruzado sin encabezados de CORP mediante COEP: sin credenciales

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.

Eiji Kitamura

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 (o require-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?

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

Foto de Martin Adams en Unsplash