La Política del Mismo Origen es un mecanismo de seguridad crítico del navegador que restringe la forma en que un documento o script cargado desde un origen puede interactuar con los recursos de otros orígenes. Ayuda a evitar que los sitios maliciosos lean datos confidenciales de otros sitios web. La política considera que dos URL tienen el mismo origen si comparten el mismo protocolo, host y número de puerto.
La política del mismo origen (SOP, del inglés same-origin policy) es la regla de aislamiento fundamental del navegador. Considera que dos URL tienen el mismo origen solo cuando comparten el mismo esquema, host y puerto, de modo que https://shop.example:443 y http://shop.example o https://api.example son orígenes distintos. Bajo la SOP, un script que se ejecuta en un origen puede cargar algunos recursos de otros orígenes (imágenes, scripts, estilos), pero no puede leer las respuestas, inspeccionar el DOM de otro origen ni acceder a sus cookies, localStorage e IndexedDB. La política la aplica el propio navegador, no el servidor, y opera por origen y no por página. Sin ella, cualquier pestaña que abrieras podría leer en silencio tu sesión de correo web o de banca en otra pestaña.
La SOP es lo que impide que un sitio malicioso interactúe mediante scripts con tus sesiones iniciadas en otros lugares. Como los navegadores adjuntan tus cookies a las peticiones de forma automática, una página podría, de lo contrario, lanzar un fetch a tu banco y leer el saldo de la cuenta desde la respuesta. La SOP bloquea esa lectura, y por eso el cross-site request forgery y el robo de datos entre orígenes quedan limitados. No es absoluta: gobierna la lectura, no el envío, así que las peticiones que cambian estado igual pueden dispararse, y una configuración incorrecta de CORS, manejadores de postMessage permisivos o un XSS ejecutándose dentro del origen de confianza la eluden. La SOP es una frontera entre orígenes, no una defensa contra código que ya se ejecuta dentro de tu propio origen.
Trata la SOP como un valor predeterminado que conviene preservar, no como un obstáculo que hay que sortear. Cuando de verdad necesites acceso entre orígenes, usa CORS con una lista de permitidos estricta en lugar de reflejar orígenes arbitrarios o poner comodines en endpoints que manejan credenciales. Valida el origen de cada evento postMessage antes de actuar sobre él, delimita las cookies con cuidado y mantén los tokens de autenticación fuera de localStorage, donde cualquier script del mismo origen puede leerlos. La brecha más difícil de cerrar es un script que se ejecuta dentro de tu propio origen, ya que la SOP le otorga plena confianza. Monitorear lo que tus scripts de terceros hacen realmente en tiempo de ejecución, que es el núcleo de la seguridad del lado del cliente, es la forma de detectar el abuso de esa confianza heredada.
No. La SOP restringe la lectura de respuestas de otros orígenes, no el envío de las peticiones. Una página aún puede enviar una petición a otro origen, y el navegador adjunta tus cookies. La SOP simplemente impide que la página que envía lea lo que regresa, y por eso siguen siendo necesarias defensas contra CSRF como las cookies SameSite y los tokens.
No. app.example.com y api.example.com son orígenes distintos porque el host difiere, así que la SOP los aísla de forma predeterminada. Los sitios relacionados pueden flexibilizar algunas interacciones mediante cabeceras CORS o, en casos heredados muy concretos, document.domain, pero los navegadores restringen cada vez más esos resquicios en favor de un CORS explícito.
We answer client-side security questions every day. Bring yours.