Resumen

  • Un borrador del W3C de febrero de 2007 ya proponía que el dueño de un recurso permitiera ciertas lecturas desde otros sitios. En marzo de 2009, el borrador Cross-Origin Resource Sharing describía con mayor detalle cómo comunicar el origen de quien pide y la respuesta del servidor.
  • La recomendación de enero de 2014 estableció una comprobación de lectura en el navegador basada en Access-Control-Allow-Origin. Algunas peticiones necesitan una consulta OPTIONS previa, pero una petición sencilla puede llegar al servidor aunque luego el programa no pueda leer su respuesta.

Un mapa meteorológico quiere números alojados en otro dominio. Hace la petición y espera. Ahí aparece una regla antigua de los navegadores: una página no recibe por defecto libertad para leer las respuestas de cualquier otro origen. La ubicación de los datos es pública; el derecho de un programa a inspeccionar la respuesta es otra cuestión. CORS puso al propietario del recurso a dar la respuesta a esa segunda pregunta.

El borrador del W3C del 15 de febrero de 2007, Enabling Read Access for Web Resources, exploraba permisos anunciados mediante una cabecera HTTP o una instrucción XML. Permitía ensayar distintos patrones de anfitrión; todavía no era el protocolo final. Su intuición duradera era sencilla: el dueño del recurso podía abrir la lectura que el navegador normalmente cerraba. El borrador de CORS del 17 de marzo de 2009 dio forma a la conversación con una cabecera de origen en la petición y cabeceras de permiso en la respuesta.

En la recomendación del W3C del 16 de enero de 2014, el servidor responde con Access-Control-Allow-Origin. Puede nombrar al origen solicitante; el navegador coteja ese valor antes de poner la respuesta a disposición del programa de la página. El asterisco funciona como permiso amplio para recursos compartidos sin credenciales. Si la petición lleva credenciales, el permiso exige un origen que coincida y Access-Control-Allow-Credentials: true. La lista de invitados deja de ser una metáfora cuando el navegador compara caracteres.

No todas las visitas empiezan llamando al timbre. Cuando el programa intenta un método o cabeceras propias fuera del conjunto sencillo, el navegador envía primero una petición OPTIONS. Ese paso preliminar pregunta qué métodos y cabeceras acepta el destino para ese origen. Si la contestación sirve, puede seguir la petición principal; el navegador también puede guardar durante un tiempo la autorización preliminar. La mecánica está definida para ciertas peticiones, no para cualquier intercambio entre sitios.

El detalle que suele perderse entre diagramas de flechas es decisivo: una petición sencilla puede alcanzar el servidor antes de que el navegador decida si comparte la respuesta con el programa solicitante. El servidor puede haber recibido y ejecutado algo. Por eso la recomendación separa expresamente el permiso de la petición y sus efectos del permiso para leer la representación devuelta. Un banco que autoriza transferencias mirando solo una cabecera de lectura tiene un problema que CORS no va a resolverle. El servidor conserva la responsabilidad sobre usuarios, acciones y consecuencias.

La historia de publicaciones del W3C enlaza los intentos de 2007 con el anuncio de la recomendación de 2014; también registra que aquel documento se retiró en 2020. Dentro de esa historia, la solución era concreta: el recurso declara qué otros orígenes pueden leer su respuesta, el navegador hace la comprobación y la aplicación usa los datos si obtiene permiso. El vecino sigue siendo dueño de la casa, aunque preste una taza de cifras.