Aislamiento entre orígenes: cabeceras y SharedArrayBuffer

El aislamiento entre orígenes es un estado de seguridad del navegador que resulta de una combinación compatible de políticas de respuesta y relaciones entre documentos. Puede habilitar funciones web como SharedArrayBuffer en los navegadores compatibles, pero no vuelve utilizables todos los recursos de otros orígenes. Un despliegue de nivel superior suele combinar Cross-Origin-Opener-Policy: same-origin (COOP) con un valor de Cross-Origin-Embedder-Policy (COEP), como require-corp o, cuando el soporte y el caso de uso lo permiten, credentialless. Después, el documento puede consultar window.crossOriginIsolated para confirmar el estado resultante en el navegador.

La decisión de despliegue va más allá de «añadir dos cabeceras». COOP cambia la relación de la página con ventanas abiertas desde otros orígenes; COEP cambia qué recursos incrustados pueden cargarse. Esto puede afectar el inicio de sesión mediante ventanas emergentes, los pagos, la analítica, los medios, las fuentes, los marcos y los scripts de proveedores. Antes de activar código que dependa de funciones exclusivas del aislamiento, inventaría esas dependencias, revisa sus respuestas reales y despliega la política por etapas con una alternativa y un plan de reversión explícitos. Es una decisión de arquitectura con costes de compatibilidad.

Qué cambia con el aislamiento

El modelo de aislamiento entre orígenes de WHATWG HTML describe un estado del navegador, no un túnel de red ni una propiedad que pueda establecer un script. La página adopta una relación más estricta con otros contextos de navegación y recursos incrustados. Si el navegador acepta la política aplicable y los requisitos de relación entre documentos, expone el estado resultante mediante crossOriginIsolated. Esa es la comprobación de ejecución que conviene registrar: que el servidor envíe una cabecera no demuestra por sí solo que el documento cargado esté aislado.

Un origen distinto puede diferir en esquema, host o puerto. Por eso, un subdominio de la misma organización también puede ser de otro origen. Los límites de origen no son lo mismo que los límites de sitio; un nombre de CDN, un dominio de recursos o un marco alojado por un cliente puede cambiar la política que se aplica. Un recurso que funciona en el entorno local puede tener otro origen y otra configuración de respuesta en producción.

El aislamiento suele mencionarse junto con SharedArrayBuffer, pero es solo un caso de uso. Algunas aplicaciones lo necesitan para bibliotecas o capacidades de ejecución compatibles. Las condiciones exactas pueden variar entre navegadores y versiones de plataforma. Un contexto seguro y un documento aislado son requisitos habituales, pero no garantizan que toda función esté disponible en cada entorno. Comprueba los datos de soporte de la API concreta y prueba el documento desplegado. No deduzcas la disponibilidad a partir del agente de usuario o de una cabecera presente.

window.crossOriginIsolated indica si el navegador considera aislado el entorno global actual. No identifica qué cabecera o recurso incrustado impidió el aislamiento. Un diagnóstico útil combina ese valor con la URL final, las cabeceras pertinentes, la versión del navegador y un inventario controlado de recursos. Limita el informe a hechos de configuración; no necesita datos de usuario ni atributos ajenos del navegador.

COOP y COEP cumplen funciones distintas

COOP controla la relación del documento con contextos de navegación de nivel superior, incluidas las relaciones opener. Con Cross-Origin-Opener-Policy: same-origin, en los casos pertinentes la página queda separada de documentos de otros orígenes en un grupo de contextos de navegación. Esto refuerza el aislamiento entre ventanas, pero puede cambiar flujos que dependen de window.opener, como una ventana de inicio de sesión que devuelve un resultado a la página que la abrió. La referencia de COOP de MDN describe sus valores y efectos. Prueba los flujos de inicio de sesión, pago y soporte con ventanas emergentes; no supongas que permanecen intactos.

COEP controla la carga de recursos de otros orígenes que un documento incrusta. Con Cross-Origin-Embedder-Policy: require-corp, normalmente el recurso debe solicitarse mediante CORS y devolver una respuesta CORS válida, o servirse con una respuesta compatible de Cross-Origin-Resource-Policy (CORP). Un recurso que antes se cargaba con una solicitud sin CORS puede quedar bloqueado si no autoriza su inclusión. El propietario del recurso o la CDN quizá deba devolver Access-Control-Allow-Origin para una solicitud CORS o una respuesta Cross-Origin-Resource-Policy adecuada para un recurso sin CORS que cumpla las condiciones. La cabecera correcta depende del tipo de recurso, las credenciales y el límite de uso compartido previsto.

El modo COEP credentialless puede relajar el requisito CORP para ciertos recursos sin CORS al cargarlos sin credenciales. Cambia el comportamiento de la solicitud: no envía cookies ni otras credenciales en esas peticiones. Antes de elegirlo, comprueba el soporte y el comportamiento detallado en documentación vigente del navegador. No es un interruptor general de compatibilidad y no sirve para recursos que necesitan autenticación. La guía de aislamiento de MDN resume la combinación de políticas y sus consecuencias.

Las funciones son complementarias. COOP por sí sola no impone los controles de recursos incrustados de COEP. En el despliegue aislado habitual, COEP por sí sola tampoco aporta la separación de nivel superior necesaria. El estado final depende de toda la política y de las relaciones entre documentos, no de un ajuste manual. No debilites la política globalmente para cargar un script de proveedor: identifica el recurso, confirma quién lo controla y elige CORS, CORP, un proxy aprobado o una integración alternativa que corresponda al acceso previsto.

Recursos incrustados y límites de origen

Antes de aplicar COEP, inventaría todos los recursos que la página puede incrustar o solicitar: scripts, hojas de estilo, fuentes, imágenes, audio, vídeo, Workers, marcos anidados y recursos cargados por código de terceros. Clasifica cada uno como mismo origen, otro origen con CORS, otro origen con CORP o integración que no puede cumplir la política elegida. Inspecciona las respuestas reales en preproducción. La URL no demuestra que la respuesta incluya la cabecera requerida, que una redirección mantenga el origen previsto ni que una solicitud con credenciales tenga una respuesta CORS compatible.

Usa una tabla de compatibilidad con una persona responsable y una decisión para cada dependencia:

Caso de dependencia	Evidencia que revisar	Decisión de despliegue
Recurso de la aplicación en el mismo origen	URL final y estado de respuesta	Mantenerlo en el mismo origen y revisar las redirecciones
Recurso de otro origen destinado al uso público	Modo CORS y Access-Control-Allow-Origin, o respuesta CORP adecuada	Acordar la configuración con su propietario y probar la respuesta real
Solicitud de otro origen que necesita credenciales	Modo de credenciales, origen permitido exacto y cabeceras de credenciales	Definir un contrato CORS deliberado; no sustituirlo por credentialless
Recurso de proveedor que no puede autorizar su inclusión	Responsable, propósito y carácter esencial	Sustituirlo, usar un proxy con diseño aprobado, aplazarlo o mantener una alternativa sin aislamiento
Ventana emergente o flujo con marco de otro origen	Comportamiento de opener, origen del marco y relación de políticas	Probar el recorrido completo con la política objetivo

Un iframe de otro origen es un documento independiente con su propia relación de origen y políticas. No des por hecho que el valor crossOriginIsolated de la página superior describe automáticamente cada marco hijo ni le concede todas las capacidades. Confirma las reglas de inserción y la delegación necesaria para la función concreta; después, comprueba el estado del propio hijo en un fixture que registre el origen esperado. El marco puede necesitar también su propia respuesta compatible. Si no controlas ese marco, coordina con su propietario antes de depender de una función exclusiva del aislamiento dentro de él.

La política debe seguir el principio de mínimo privilegio. Permite solo los orígenes y tipos de recursos que necesita la aplicación y evita que las integraciones de terceros amplíen el acceso sin aviso. Una respuesta CORS con comodín puede ser válida para un recurso público sin credenciales, pero no resuelve universalmente los datos autenticados. Los valores CORP también expresan quién puede incrustar la respuesta; elige uno que corresponda a la relación prevista, no el más amplio por defecto. Documenta quién mantiene cada cabecera cuando la página, la CDN, el proveedor de identidad y el servicio incrustado pertenecen a equipos distintos.

Fixture determinista de despliegue

Este fixture muestra el estado de aislamiento, compara el resultado con una expectativa declarada por el caso de prueba y elimina el DOM temporal aunque falle una aserción o el informe. Sírvelo desde el mismo origen y por la misma ruta de cabeceras que la aplicación. En el entorno candidato aislado configura true; en un control sin la política completa declara la expectativa por separado. No la derives del valor que estás probando.

async function checkIsolation(expected) {
  const host = document.createElement('section');
  const status = document.createElement('output');
  status.setAttribute('aria-live', 'polite');
  host.append(status);
  document.body.append(host);

  try {
    const isolated = window.crossOriginIsolated === true;
    const sharedMemoryAvailable = typeof SharedArrayBuffer === 'function';
    const passed = expected ? isolated && sharedMemoryAvailable : isolated === expected;
    status.textContent = `${passed ? 'PASS' : 'FAIL'}: isolated=${isolated}; SharedArrayBuffer=${sharedMemoryAvailable}`;

    console.assert(passed, status.textContent);
    if (expected) console.assert(sharedMemoryAvailable, 'Expected SharedArrayBuffer in this declared browser case');
    return { passed, isolated, sharedMemoryAvailable, visibleResult: status.textContent };
  } finally {
    host.remove();
  }
}

// La configuración de prueba declara esta expectativa para el origen candidato.
await checkIsolation(true);

El fixture informa de dos hechos separados: el estado de aislamiento del navegador y si este entorno expone SharedArrayBuffer. Un caso de navegador incluido en la matriz de soporte puede exigir ambos; otro navegador puede registrar que la API no está disponible y ejercitar la alternativa del producto. La alternativa debe tener su propio resultado esperado, no convertirse en un falso aprobado de aislamiento. El ejemplo no asigna memoria compartida, inicia Workers ni realiza mediciones; verifica la respuesta y la elegibilidad de ejecución sin añadir otra carga.

Para probar compatibilidad de recursos, sirve una página propia pequeña que cargue un recurso representativo de otro origen por cada categoría necesaria. Asigna una URL estable a cada recurso y comprueba un estado visible de carga o error. Usa un fixture por caso de política para que el fallo de una fuente no oculte el resultado de un script o marco. Incluye redirecciones y credenciales solo cuando la dependencia de producción las utilice. En el desmontaje, elimina los nodos del fixture y cierra el contexto de prueba aislado; no alteres datos compartidos de producción.

Despliegue, observación y reversión

Despliega por etapas. Primero inventaría las dependencias entre orígenes e identifica a sus propietarios. Después configura un origen de preproducción con COOP y el valor COEP elegido, y ejecuta el fixture y el flujo completo. Verifica las cabeceras en la respuesta final del documento, no solo en el balanceador o archivo de configuración: las redirecciones, reglas CDN, Service Workers y rutas por host pueden cambiar lo que llega al navegador. Confirma crossOriginIsolated después de navegar la página real y prueba cada recurso esencial con el modo de solicitud usado en producción.

Antes de extender el cambio, prueba los flujos entre contextos: autenticación con ventanas emergentes, pagos, marcos de clientes, herramientas de ayuda y cualquier integración que use referencias opener. Prueba también las versiones de navegador en los límites del soporte y un control que use la alternativa. Conserva un informe breve con URL final, compilación del navegador, valores COOP y COEP, estado de aislamiento, fallos de recursos, orígenes de marcos y resultado visible. No guardes secretos, datos de cuentas ni información ajena del perfil.

El despliegue solo está listo cuando se observa el estado aislado donde corresponde, se cargan los recursos necesarios bajo la política declarada y las personas pueden terminar la tarea principal si la función no está disponible. Si un recurso de proveedor bloquea el cambio, conserva la alternativa o reemplaza la integración; no debilites globalmente la política sin documentarlo. Un fallo de aislamiento es un resultado de configuración que debe diagnosticarse, no un motivo para cambiar las aserciones en silencio.

Prepara la reversión antes de modificar las cabeceras de producción. Conserva disponibles la política y la versión anteriores. Si la nueva política rompe una integración esencial, restaura conjuntamente la política y el flujo de aplicación que funcionaban, y vuelve a ejecutar el mismo fixture para confirmar el estado no aislado y la alternativa prevista. La compilación de reversión debe quitar las rutas que exigen la función exclusiva del aislamiento o protegerlas con la comprobación de ejecución. Mantén la seguridad del transporte y las otras cabeceras; revertir no justifica servir por HTTP ni borrar las pruebas.

Qué puede validar BotBrowser

BotBrowser permite ejecutar QA autorizado de aplicaciones con contextos controlados del navegador: un equipo puede usar contextos aislados para ejecutar un fixture propio en una versión declarada, comprobar el estado de aislamiento y comparar la alternativa visible sin arrastrar el estado de un recorrido ajeno. La documentación de aislamiento de varias cuentas de BotBrowser describe contextos distintos para sesiones independientes. BotBrowser no puede aislar entre orígenes un documento, servir cabeceras COOP o COEP, cambiar la respuesta CORS/CORP de un recurso externo, conservar un comportamiento de ventana emergente que la política separa intencionalmente ni garantizar que todas las plataformas admitan SharedArrayBuffer. El modelo de aislamiento de WHATWG HTML y la configuración del sitio siguen siendo la referencia. Usa BotBrowser para observar un recorrido declarado; los equipos de aplicación e infraestructura siguen siendo responsables de los contratos de recursos, las políticas, la compatibilidad y la reversión.

Para continuar, consulta la guía de validación de versiones de navegador, la guía de contextos seguros y la guía de compatibilidad de API. Tratan las evidencias de versión, la elegibilidad del contexto y la planificación de alternativas; esta página se centra en las políticas de respuesta y recursos necesarias para el aislamiento entre orígenes.

Registra la decisión de publicación con el responsable de cada política y contrato de recursos. Así una reversión posterior puede revisarse: el equipo puede distinguir un cambio en la respuesta del documento, una redirección, una regla CDN o una dependencia incrustada. Limita el registro a respuestas técnicas y resultados visibles, y repite las mismas comprobaciones después de cada cambio de política.

Si una dependencia opcional falla, documenta la alternativa visible; si es esencial, detén el lanzamiento hasta que su propietario confirme una respuesta compatible.

Fuentes

• WHATWG HTML: aislamiento entre orígenes
• MDN: aislamiento entre orígenes
• MDN: Cross-Origin-Opener-Policy
• MDN: Cross-Origin-Embedder-Policy
• MDN: SharedArrayBuffer
• BotBrowser: aislamiento de varias cuentas