Resumen

  • El borrador Origin de enero de 2009 ofrecía al servidor una pista sobre el contexto que había iniciado una petición y proponía usarla frente a solicitudes falsificadas entre sitios. El RFC 6454 de diciembre de 2011 fijó la idea más amplia de origen web.
  • El navegador reúne esquema, host y puerto en una misma unidad de confianza. La ruta queda fuera de la cuenta: una página ajena alojada como HTML activo bajo ese mismo origen entra en el espacio de la aplicación.

La carpeta no era una frontera

Un servicio deja las cuentas en /cuentas y abre /usuarios para publicar textos de terceros. A simple vista parecen dos barrios. Para el navegador, si comparten https, host y puerto, son el mismo origen. La palabra que sigue a la barra no concede ni retira derechos.

El RFC 6454, de diciembre de 2011, puso números a esa intuición. Describe una política de mismo origen que ya se había formado en la práctica, y explica por qué los navegadores no tratan cada URL como una isla: una aplicación suele repartir su trabajo entre muchas páginas. El origen agrupa esos recursos para que cooperen. La comodidad tiene dueño. Quien administra el servidor decide qué material ocupa ese espacio común.

El documento ofrece una comparación útil. Una página HTTP en example.com y otra ruta del mismo host con el puerto 80 explícito comparten origen; 80 es el puerto normal de HTTP. Si cambia el puerto, cambia el origen. Si la dirección pasa a HTTPS, también cambia, aunque el host sea idéntico. Una página descargada sin la protección de HTTPS no recibe por accidente la autoridad del lado cifrado. En cambio, /cuentas y /usuarios siguen dentro del mismo perímetro cuando el trío de esquema, host y puerto coincide.

El HTML invitado traía equipaje

El problema aparece cuando una contribución deja de ser un archivo pasivo y llega como HTML capaz de ejecutar código. El RFC advierte sobre el contenido de usuarios bajo la misma autoridad y subraya el papel del tipo de medio servido. El servidor puede exigir credenciales para una operación; eso es otra comprobación. El navegador ya habrá clasificado la página según su origen y le habrá asignado el contexto correspondiente.

Por eso una ruta llamada /contenido-seguro no arregla nada por sí sola. Importan el host que responde, el puerto al que se conecta el cliente y los bytes que el servidor entrega como HTML. El diseño de alojamiento se convierte en una decisión sobre privilegios. El nombre de una carpeta es, como mucho, un aviso para la persona que administra el sistema.

En el borrador Origin de enero de 2009, el punto de partida era una petición recibida por el servidor. La propuesta describía un encabezado Origin con el contexto que había provocado esa petición, útil para examinar ataques de falsificación entre sitios. Aquel texto era un Internet-Draft, no una norma aprobada. Dos años después, RFC 6454 ordenó la noción de origen como base de las decisiones del navegador y explicó cómo serializarla en la petición. Cuando no existe un trío ordinario, la representación ASCII es null; el RFC también pide esa respuesta en contextos sensibles para la privacidad.

La Recomendación CORS de 2014 tomó el origen como dato para decidir quién puede leer una respuesta de otro sitio. Su texto separa esa lectura de la autorización para ejecutar los efectos de la petición. Esa invitación tiene su propia historia. La pregunta anterior es más áspera: ¿a quién considera el navegador miembro de la misma casa antes de pedir permiso a nadie?

El RFC dejó la regla por escrito. El navegador contaba el puerto y se saltaba la ruta. Los editores de sitios quedaron a cargo de lo que metían dentro.