La política del mismo origen: qué es un origen y qué aísla

Qué es

El RFC 6454 define un origen como la tupla de esquema, host y puerto; MDN lo llama la «tupla esquema/host/puerto». https://example.com, https://example.com:8443, http://example.com y https://app.example.com son cuatro orígenes distintos; la ruta y la query no influyen. La política del mismo origen es la regla del navegador para las interacciones entre orígenes. MDN las clasifica en tres grupos: las escrituras entre orígenes (enlaces, redirecciones, envíos de formularios) suelen estar permitidas; la incrustación entre orígenes (img, script, iframe, hojas de estilo, fuentes) suele estar permitida, pero el contenido incrustado es opaco para el script; las lecturas entre orígenes (el DOM de otra ventana o frame, el cuerpo de una respuesta de fetch, el almacenamiento de otro origen) suelen estar prohibidas. CORS es la adhesión voluntaria del lado del servidor que relaja las lecturas. Las cookies siguen su propio ámbito: el RFC 6265 señala que no proporcionan aislamiento por puerto.

Por qué importa

Esta política es la razón por la que una página hostil no puede cargar el banco de alguien en un frame oculto y leer el saldo, y también la razón por la que un front-end legítimo en otro origen no puede leer las respuestas de una API hasta que esta lo permite. De su malentendido se derivan dos tipos de error: abrir CORS a cualquier origen con credenciales porque «el navegador lo bloqueó», y suponer que la política impide la falsificación de solicitudes entre sitios (CSRF), lo cual no es cierto, porque las escrituras están permitidas.

Cómo aplicarlo

• Preferir un único origen para la aplicación y la API (un proxy inverso bajo un solo host); esto elimina la configuración de CORS y mantiene simples las cookies.
• Tratar los subdominios como ajenos para el script y el almacenamiento; una cookie con Domain=example.com los abarca a todos, lo cual importa cuando un subdominio aloja contenido de usuarios.
• No usar nunca document.domain para relajar la comprobación; MDN lo marca como obsoleto porque socava el aislamiento.
• Intercambiar datos con frames de terceros incrustados mediante postMessage con un origen de destino explícito, y verificar event.origin al recibir el mensaje.
• Proteger los endpoints que cambian estado con tokens CSRF o cookies SameSite; la política no lo hará.
• Controlar quién puede incrustarse en un frame propio con la directiva CSP frame-ancestors, y quién puede cargar los subrecursos propios con Cross-Origin-Resource-Policy.

Trampas

Durante el desarrollo, http://localhost:3000 y http://localhost:5173 son orígenes distintos, razón por la cual los servidores de desarrollo ofrecen proxies. Un iframe de otro origen no puede ser inspeccionado por la página padre, aunque esta sí puede navegarlo. Una respuesta obtenida con mode: "no-cors" es opaca: la página que la solicitó no puede leer ni su estado ni su cuerpo.