Summary

  • La versión del 27 de octubre de un borrador CDNI advierte de que una respuesta con Access-Control-Allow-Origin: * puede salir de una caché compartida hacia un origen ausente de la lista permitida si falta la variación adecuada.
  • El texto sitúa la decisión CORS en el navegador conforme: los encabezados rigen la exposición de una respuesta pública al código de una página, mientras que el CDN de destino sigue sirviendo el recurso.

El portero consulta la lista y deja pasar al invitado correcto. Un armario compartido guarda una pulsera dorada y se la entrega después a quien no figuraba en la lista. El primer control funcionó. Lo que falló fue el viaje de la señal. La revisión -13 del borrador de metadatos CDNI describe ese viaje con orígenes web, un encabezado CORS comodín y una caché compartida.

El CDN ascendente puede enviar MI.CrossoriginPolicy al CDN descendente por la interfaz de metadatos de RFC 8006. La política incluye una lista de orígenes admitidos. El borde compara la cabecera Origin de la petición con ella. Si coincide y wildcard-return está activado, puede devolver Access-Control-Allow-Origin: *; si no coincide, omite los encabezados CORS correspondientes. La estrella permite al navegador tratar la respuesta de esa petición. No cuenta por sí sola qué origen pasó el control.

Por eso la caché importa. Si conserva o reutiliza para otra petición una respuesta que lleva * sin distinguir las cabeceras de origen pertinentes, un origen excluido puede recibir la pulsera del admitido. El nuevo apartado operativo hace explícito ese riesgo. El borrador exige al CDN descendente generar las cabeceras CORS para cada respuesta, en vez de guardarlas como parte de la representación en caché, e incluir en Vary los nombres de las cabeceras de petición que modifican la respuesta CORS.

La versión -12 ya definía los objetos; -13 precisa el terreno que pisan. CORS lo aplica un agente de usuario conforme cuando decide si un script de otro origen puede leer una respuesta. El CDN descendente sigue sirviendo el recurso públicamente accesible aun cuando no añada las cabeceras CORS. Las peticiones que incluyen credenciales del navegador quedan fuera de estos objetos, porque combinar CORS con autenticación y autorización requiere comportamiento adicional.

También hay un intervalo entre publicar la política y recibirla. Si el CDN ascendente hace disponible el recurso antes de que el borde reciba MI.CrossoriginPolicy, el borde lo sirve sin cabeceras CORS y el navegador falla la comprobación. El borrador señala que los operadores pueden recuperar la configuración que el CDN descendente tiene en vigor mediante RFC 8006 y compararla con lo que observan. No incorpora un nuevo sistema de vigilancia para hacerlo por ellos.

El Datatracker del IETF sitúa la versión -13 de este borrador de grupo de trabajo en evaluación por el IESG. La pregunta útil para los operadores no es solo quién escribió la lista. Es quién comprobó la pulsera que salió de la caché.