Reversión del aislamiento cross-origin: lista de comprobación

Cambiar el aislamiento cross-origin es cambiar la política de respuesta de un producto en producción, y lo difícil no es activarlo. Esta lista empieza donde termina la guía para corregir el error not cross-origin isolated: cuando la primera página ya se acredita como aislada, hay que decidir qué URL deben seguir así, quién responde por cada recurso embebido y qué hace una publicación escalonada si un flujo se rompe.

BotBrowser puede cargar una versión de navegador declarada contra una página propia y registrar si window.crossOriginIsolated es verdadero para esa respuesta; no puede enviar COOP ni COEP por un host, cambiar la respuesta CORS o CORP de un proveedor, ni restaurar un flujo que la nueva política separa.

Resumen

• Enumera las URL que necesitan aislamiento y deja el resto sin aislar a propósito.
• Asigna cada clase de recurso embebido a un responsable de política antes de tocar una cabecera.
• Publica por porcentaje o por host, no abriendo todas las rutas a la vez.
• Acuerda el disparador de reversión y el juego de cabeceras anterior antes de la primera petición en producción.

Contenido

• Delimitar las URL que necesitan aislamiento
• Asignar clases de recurso a responsables
• Escalonar la publicación
• Definir la reversión
• Publicar la alternativa y la evidencia
• Conclusión práctica

Delimitar las URL que necesitan aislamiento

El aislamiento pertenece a los documentos, no al sitio. Un producto suele necesitarlo en una sola superficie, por ejemplo una página que arranca un worker con memoria compartida, y no lo necesita en una página de presentación, en un inicio de sesión ni en un callback de OAuth. Enviar Cross-Origin-Opener-Policy: same-origin y Cross-Origin-Embedder-Policy: require-corp en todas partes amplía el radio de impacto sin aportar nada a las páginas que nunca usan una función exclusiva del aislamiento. Antes de ampliar el alcance, relee la guía de límites CORS, que describe qué recursos ya cuentan como dependencia cruzada.

Escribe el alcance como una lista de patrones de URL como /app/editor/* y /auth/*, no como un dominio. Incluye las rutas de documento que deben aislarse, las que deben quedarse sin aislar y las rutas de callback cuya ventana emergente no puedes cambiar. Una cadena de redirecciones que termina en un documento aislado sigue aislada; la que termina en uno no aislado, no, y esa diferencia se pierde cuando el alcance se escribe como «la aplicación».

Registra el alcance junto al registro de publicación (docs/cross-origin-isolation-scope.md), con fecha y responsable. Cuando más adelante se añade una ruta, el alcance dice si hereda el aislamiento de un patrón padre o necesita su propia política. Esa es la diferencia entre una política intencionada y una que se extendió por accidente.

Comprueba el alcance contra el sitemap y el manifiesto de rutas en lugar de contra la memoria, y automatiza esa comparación si el conjunto de rutas cambia a menudo. Una ruta generada por una plantilla puede servir un documento que tu regla de cabeceras no cubre, sobre todo si la plantilla tiene su propio layout y un host canónico distinto. El primer sitio donde el aislamiento sorprende a un equipo es una página que nadie listó.

Mantener el alcance revisable

Revisar el alcance es también el momento de confirmar que las páginas sin aislar no necesitan de verdad una función exclusiva del aislamiento. Busca SharedArrayBuffer, crossOriginIsolated y Atomics en la aplicación antes de declarar una página fuera de alcance. Una página que consulta el booleano y se repliega puede quedarse sin aislar; una que construye un búfer compartido sin consultarlo lanzará un error en cuanto se ejerza esa función.

Si una página necesita aislamiento solo bajo un indicador de función, registra el indicador junto al patrón. Activar el indicador en un host que no envía la política produce un fallo en tiempo de ejecución que parece un defecto de código, y el registro del indicador permite ver que la política nunca estuvo en su sitio y no que la función se degradó.

Escribir el alcance como lista verificable

Un alcance que vive en una presentación no se puede comprobar, así que guarda el estado esperado como una fila de scopes.tsv o un campo JSON que la compilación pueda leer. Mantenlo como una lista de patrones con un estado esperado por patrón, para que un cambio posterior se compare con ella en lugar de discutirse. Una entrada útil nombra el patrón, el estado de aislamiento esperado, el motivo y el responsable que lo pidió.

El estado esperado no siempre es «aislado». Muchos productos necesitan que un documento siga sin aislar porque un widget de chat, un iframe de pago o un informe heredado depende de recursos que nadie puede cambiar en la misma ventana. Registrar esa intención evita que una limpieza posterior «arregle» una página excluida a propósito y rompa un flujo en el proceso.

Agrupa los patrones por su ruta de respuesta y no solo por el prefijo de URL. Dos rutas bajo el mismo prefijo pueden servirse desde orígenes distintos tras una reescritura, y una regla de CDN que aplica a una puede no aplicar a la otra. Cuando la lista pase de unos pocos elementos, añade una comprobación de que cada ruta versionada coincide con un patrón o está excluida explícitamente, para que una ruta nueva no herede sin avisar el estado equivocado.

Mantén la lista junto a la configuración de despliegue y actualízala en el mismo cambio que añade o quita una ruta. Un alcance corregido después ya estuvo mal en producción, y el fallo que causa parece una inconsistencia aleatoria y no una entrada que falta.

Medir antes y después, en la misma compilación

La medición que hace revisable una publicación es una comparación, no una lectura; guárdala como scope-before.json y scope-after.json. Toma una línea base del host de preproducción antes del cambio de política y repite las mismas comprobaciones después, con la misma compilación de navegador y los mismos fixtures. Una sola lectura posterior no dice si un valor inesperado viene de la política o ya estaba ahí.

Registra tres campos por página: los valores de cabecera entregados, el booleano de aislamiento en tiempo de ejecución y el primer recurso que falló, si lo hubo. Las cabeceras dicen qué envió el servidor; el booleano, qué aceptó el navegador; el recurso fallido, qué clase necesita atención cuando los dos primeros no coinciden.

Muestrea al menos una URL por patrón en lugar de una sola URL global. Una cadena de redirecciones, un host localizado y una variante con barra final pueden producir respuestas finales distintas, y el patrón es tan fuerte como su miembro menos probado.

Repite la medición tras un cambio de CDN, una actualización de service worker o una migración de alojamiento aunque el código de aplicación no se haya movido. Esos tres eventos cambian la respuesta entregada sin tocar el repositorio, y por eso un registro de política anterior a ellos puede inducir a error.

Asignar clases de recurso a responsables

El aislamiento cambia qué puede cargarse, así que cada clase de recurso embebido necesita una decisión y un responsable. Agrúpalas por cómo se sirve el recurso y no por qué equipo lo pidió, porque la respuesta de política depende de la respuesta del servidor y no de la petición.

Los frames son la clase más sensible. Un iframe de otro origen necesita una respuesta compatible con COEP o una cabecera CORP, y un frame de proveedor que no las envía fallará en cuanto el documento que lo embebe aplique COEP. El inicio de sesión por ventana emergente pertenece a la misma clase: COOP separa la relación con el opener, y un proveedor que espera window.opener lo notará. Registra el proveedor, el origen del frame y qué dice su documentación sobre compatibilidad con el aislamiento.

Scripts, hojas de estilo, fuentes e imágenes forman la siguiente clase. Suelen servirse desde un CDN, y la respuesta es una cabecera CORS o Cross-Origin-Resource-Policy: cross-origin. Una regla de CDN que funciona para un subdominio puede no aplicar al host canónico, así que el responsable a nombrar es quien puede cambiar la respuesta del host exacto que llamas.

Los medios son una clase propia y suelen ser los más lentos de cambiar. Los endpoints de vídeo y audio pueden estar firmados, redirigidos o segmentados por región, y cada uno de esos casos cambia las cabeceras que ves. Prueba con una URL firmada parecida a una de producción y no con una muestra estática.

La analítica y los gestores de etiquetas son la clase que más probablemente falle en silencio. Muchos cargan scripts adicionales en tiempo de ejecución, así que la URL que revisaste no es la que se ejecuta. Registra que pueden fallar y decide si la falla es aceptable, porque un beacon que deja de reportar rara vez bloquea un flujo de usuario pero sí cambia los datos en los que te apoyas.

Para cada clase, nombra la política, el responsable y la verificación. La verificación es una petición por clase, registrada con la URL final y el valor de cabecera que la hizo compatible. Una clase sin verificación es una clase que estás suponiendo en lugar de conocer, y una suposición es lo que convierte una publicación escalonada en una sorpresa.

Escalonar la publicación

Escalona por tráfico y no por ambición. Una publicación escalonada permite que la primera evidencia de producción venga de una población pequeña mientras la política anterior sigue a un cambio de configuración de distancia. Elige la dimensión de escalonado según lo que tu infraestructura revierte más rápido, medida en rollbackMinutes: un porcentaje en el borde, una regla de cabeceras en un host o una ruta canaria que sirve el mismo código.

Alinea la unidad de escalonado con el flujo del usuario. Un porcentaje de tráfico puede mandar a un mismo usuario a la versión aislada en la primera página y a la no aislada en el callback, y eso produce un fallo que parece aleatorio y no lo es. Un porcentaje pegajoso o una agrupación por host mantiene un flujo bajo una sola política durante toda su duración.

Decide el orden de las superficies. Empieza por la que tiene menos dependencias embebidas y una alternativa más clara, y termina por la que lleva inicio de sesión o pago. El objetivo del orden es aprender sobre las clases de recurso en un sitio barato antes de tocar el caro.

Vigila las señales correctas durante la ventana. Un crossOriginIsolated: false en una página que debería ser verdadera es un resultado de configuración. Un recurso bloqueado es un resultado de política contra una clase. Un usuario que no puede iniciar sesión es un resultado de aplicación y supera a los dos anteriores, porque ningún estado aislado vale más que un flujo roto.

Mantén la ventana lo bastante corta para revertir y lo bastante larga para ver un flujo completo, y escríbela en el registro antes de empezar para que nadie la amplíe por accidente. Una ventana que termina antes de que un usuario inicie sesión y vuelva por el callback no ha probado las rutas que más probablemente se rompan.

Definir la reversión

Una reversión necesita un disparador, una acción y una verificación acordados antes de empezar. El disparador es una frase que un ingeniero de soporte puede aplicar sin preguntar al responsable de la publicación: un flujo esencial falla por encima de una proporción declarada de usuarios escalonados, o el responsable de una clase no consigue hacer compatible un recurso durante la ventana.

La acción es el juego de cabeceras anterior más la ruta de aplicación anterior, ambos disponibles y probados. Una reversión de cabeceras que restaura COOP y COEP dejando la función aislada activa produce una página que informa falso y luego falla en ejecución; la ruta de aplicación tiene que cambiar con la política.

La verificación es la misma comprobación que demostró el aislamiento, ejecutada al revés: el host escalonado vuelve a las cabeceras anteriores, crossOriginIsolated es falso donde se espera, la alternativa completa el flujo y las clases que necesitaban la nueva política dejan de ser necesarias. Registra el resultado con la fecha y la persona que decidió.

Escribe lo que la reversión no cubre. Un documento en caché, un service worker o una regla de borde con TTL largo pueden seguir sirviendo la nueva política después de cambiar el origen. Anota el paso de purga y los hosts a los que aplica, porque una reversión incompleta es una política que parece revertida y no lo está.

Revisa el registro de reversión cuando termine la publicación, se haya usado o no. Una reversión que nunca hizo falta también dice si la acción funcionó, y el siguiente cambio de cabeceras puede reutilizar el procedimiento en lugar de redescubrirlo.

Publicar la alternativa y la evidencia

Elegir la alternativa que el producto sí puede publicar

Toda función exclusiva del aislamiento necesita una alternativa con la que el usuario pueda completar la tarea (fallback: passed), y la alternativa debe ser el camino más simple y no un segundo sistema. Un worker con memoria compartida puede replegarse a un bucle en el hilo principal con indicador de progreso. Una función que necesita aislamiento por rendimiento puede degradarse al camino lento con un aviso visible. Una función que necesita aislamiento por corrección no puede replegarse, y esa es una decisión de producto que hay que escalar antes de la publicación y no durante ella.

Prueba la alternativa con los mismos fixtures que prueban el camino aislado. Una alternativa que nunca corrió con datos parecidos a producción es un camino no probado, y la ventana de publicación no es el momento de descubrir que lanza un error con una entrada grande.

Decide quién es dueño de la alternativa. Si el equipo de aplicación la entrega y el de plataforma activa la cabecera, la alternativa pertenece al equipo de aplicación y debe estar en la lista de publicación, no añadirse después. El registro de publicación debe nombrar la alternativa y dónde verificarla, para que soporte pueda dirigir a un usuario allí sin esperar un diagnóstico.

Mantener la evidencia corta para actuar

Un registro de publicación que solo entiende un especialista no se lee durante un incidente. Redúcelo a la lista de alcance, los responsables por clase, la dimensión de escalonado, las lecturas antes y después, el disparador de reversión y la alternativa. Cada elemento debe caber en una línea y apuntar al documento largo cuando haga falta.

Pon fecha al registro y nombra a quien aceptó la política, junto con la zona horaria local en la que se planificó la ventana. Un registro sin responsable se convierte en un registro que nadie defiende, y el siguiente cambio parte de una posición más débil que el primero.

Retira el registro cuando la política lleve tiempo estable y el juego de cabeceras anterior ya no exista en ninguna configuración desplegable. Hasta entonces, el registro es la única descripción de cómo se llegó al estado actual.

Conclusión práctica

El aislamiento es una política de respuesta con un alcance, unos responsables y un plan de publicación. Decide las URL, asigna las clases de recurso, escalona por tráfico y acuerda el disparador de reversión antes de la primera petición en producción. Usa esta lista junto a la corrección del aislamiento, la guía de límites CORS y la visión de contextos seguros.

Fuentes

• WHATWG HTML: aislamiento cross-origin
• HTML Standard: Cross-Origin-Opener-Policy
• HTML Standard: Cross-Origin-Embedder-Policy
• MDN: Cross-Origin-Resource-Policy
• Documentación de BotBrowser: aislamiento y memoria compartida