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

Los recursos de origen cruzado atendidos por terceros a menudo no incluyen encabezados CORP adecuados. Si se pueden solicitar sin credenciales, ahora puedes habilitar el aislamiento de origen cruzado marcándolos como tales.

Eiji Kitamura

Enviamos el valor de la nueva Política de incorporaciones de origen cruzado (COEP) credentialless, que permite que el navegador cargue recursos de origen cruzado que usar la política de recursos entre dominios (CORP) enviando una solicitud sin credenciales, como cookies. Esto ayuda a los desarrolladores a adoptar orígenes cruzados el aislamiento de manera más fácil.

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 aceptación llamado aislamiento de origen cruzado. Con origen cruzado estado aislado, la página web puede utilizar funciones con privilegios, como SharedArrayBuffer: performance.measureUserAgentSpecificMemory() y temporizadores de alta precisión con mejor resolución y aísla el origen de los demás, a menos que estén habilitados.

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, se deben entregar todos los recursos de origen cruzado con CORS o configura un encabezado Cross-Origin-Resource-Policy para que se cargue.

Desafíos para habilitar el aislamiento de origen cruzado

Si bien el aislamiento de origen cruzado brinda a las páginas web una mejor seguridad y la capacidad de habilitar funciones potentes, implementarlas puede difícil. Una de las mayores desafíos es el requisito para habilitar el CORS o el CORP para todos los de Google Cloud. El navegador no cargará los recursos sin esos encabezados en una página aislada de origen cruzado.

Estos recursos de origen cruzado, por lo general, son entregados por terceros para los que pueden no será fácil agregar los encabezados necesarios.

Pero ¿qué sucede si sabemos que el recurso es lo suficientemente seguro para cargarlo? De hecho, la única recursos que están en riesgo son los solicitados con credenciales, porque incluir información confidencial que el atacante no puede cargar en su por sí solas. Esto significa que los recursos que se pueden solicitar sin credenciales están estén disponibles y sean seguros para cargar.

credentialless al rescate

Aquí es donde COEP: credentialless entra en juego. credentialless es un valor nuevo para el encabezado Cross-Origin-Embedder-Policy. Al igual que con require-corp, puede habilitar el aislamiento de origen cruzado, pero en lugar de requerir un CORP:cross-origin para las solicitudes de origen cruzado sin cors, en su lugar, se envían sin credenciales (por ejemplo, cookies).

Podrás habilitar el aislamiento de origen cruzado de manera alternativa con el 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 se alinea con la configuración plan de eliminación gradual de las cookies de terceros.

Demostración

Puedes probar varias opciones de encabezado en esta demostración: https://cross-origin-isolation.glitch.me

Preguntas frecuentes

¿Puedo enviar una solicitud con credenciales en un entorno de credentialless?

Sin duda, a costa de cambiar el modo de la solicitud para requerir una verificación de CORS en la respuesta. Para las etiquetas HTML, como <audio>, <img>, <link>, <script>, y <video>, solo debes agregar crossorigin="use-credentials" de forma explícita para informar para enviar solicitudes con credenciales.

Por ejemplo, aunque un documento en https://www.example.com tenga Encabezado Cross-Origin-Embedder-Policy: credentialless, <img src="https://images.example.com/avatar.png" crossorigin="use-credentials"> hará lo siguiente envía una solicitud con credenciales.

Para la API de fetch(), se puede usar request.mode = 'cors'.

Se proporcionó COEP: credentialless, ¿por qué COEP: require-corp sigue siendo útil para mi sitio web?

COEP: require-corp no requiere que cambies manualmente el modo de solicitud a CORS si se necesitan cookies para algunos subrecursos de origen cruzado.

¿Puedo también cargar iframes de origen cruzado sin encabezados especiales en un entorno credentialless?

No. La carga de iframes de origen cruzado en un entorno credentialless aún requiere las mismas condiciones que require-corp. Los documentos iframe deben publicarse 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 en curso sobre cómo permitir la carga de iframes de origen cruzado sin esos encabezados mediante la asignación de iframes crossorigin="anonymous". Esto permitirá que los iframes de origen cruzado se carguen sin encabezados, pero sin credenciales.

¿Otros navegadores adoptarán esta función?

¿Qué sigue?

Hay dos actualizaciones adicionales que se avecinan para mitigar otros desafíos relacionados con Aislamiento de origen cruzado:

Los usuarios que se registraron en la prueba de origen de Chrome para extender el cambio de SharedArrayBuffer debido a los obstáculos anteriores podrían preguntarse cuándo se cerrará. Originalmente, anunciamos que se resolvería en Chrome 96, pero decidimos posponerlo hasta Chrome 106.

Recursos

Foto de Martin Adams activado Eliminar salpicaduras