Explica la Same-Origin Policy y CORS.
Respuesta breve
La Same-Origin Policy es la regla del navegador según la cual un script de un origen (esquema + host + puerto) no puede leer las respuestas de un origen diferente, lo que protege las sesiones autenticadas. CORS es una relajación controlada: un servidor devuelve cabeceras Access-Control-Allow-Origin para habilitar explícitamente que orígenes concretos lean sus respuestas, por lo que flexibiliza la SOP en lugar de eludirla.
La Same-Origin Policy (SOP) es la frontera de seguridad fundamental de la web. Sin ella, cualquier sitio que visites podría leer silenciosamente tu correo web, tu banco o tu consola de administración con sesión iniciada usando tus propias cookies. La SOP lo impide.
La Same-Origin Policy
Un origen es el triple de esquema + host + puerto (https://app.example.com:443). La SOP dice que un script que se ejecuta en un origen generalmente no puede leer la respuesta de una petición a un origen diferente. Nota el matiz: el navegador a menudo seguirá enviando la petición entre orígenes (que es exactamente por lo que existe el CSRF), pero impide que el script lea el resultado. Esto es lo que evita que una página maliciosa recopile datos de tus sesiones autenticadas en otros lugares.
Por qué existe CORS
La SOP es deliberadamente estricta, pero las aplicaciones legítimas necesitan constantemente datos entre orígenes — un front-end en app.example.com llamando a una API en api.example.com. Cross-Origin Resource Sharing (CORS) es el mecanismo por el cual el servidor habilita el compartir. Flexibiliza la SOP de forma controlada; no la desactiva.
Cómo funciona CORS
El navegador añade una cabecera Origin; el servidor responde con Access-Control-Allow-Origin nombrando los orígenes autorizados a leer la respuesta. Para peticiones que pueden cambiar el estado o que usan cabeceras/métodos no simples, el navegador envía primero una petición de comprobación previa OPTIONS, y el servidor debe aprobar el método y las cabeceras mediante Access-Control-Allow-Methods / -Headers antes de que se envíe la petición real.
El error de seguridad común
Para enviar cookies entre orígenes debes establecer Access-Control-Allow-Credentials: true — y en ese caso la especificación prohíbe el comodín Access-Control-Allow-Origin: *; debes devolver un origen específico. Reflejar ingenuamente el Origin de la petición con las credenciales habilitadas es una mala configuración clásica que permite que cualquier sitio lea respuestas autenticadas.
Los entrevistadores buscan la definición esquema/host/puerto, la sutileza «bloquea la lectura, no el envío», CORS como habilitación del servidor que relaja (no desactiva) la SOP, y la trampa de credenciales más comodín.
Posibles preguntas de seguimiento
- ¿Qué hace que dos URL sean del 'mismo origen'?
- ¿Qué es una petición de comprobación previa (preflight) de CORS y cuándo se envía?
- ¿Por qué se prohíbe Access-Control-Allow-Origin: * con credenciales?