Origen cruzado: qué permite una política CORS laxa

Dos URL tienen el mismo origen si coinciden en esquema, nombre de host y puerto. https://www.boletas-jerusalen.example y https://api.boletas-jerusalen.example son orígenes distintos aunque pertenezcan a la misma empresa. Por defecto, el código de una página puede enviar peticiones a otro origen, pero el navegador no le entrega la respuesta: la política del mismo origen protege la lectura.

CORS es la forma en que un servidor relaja esa regla. Cuando la petición viene de otro origen, el navegador manda la cabecera Origin y mira la respuesta: si Access-Control-Allow-Origin nombra ese origen (o es *), deja que el código lea el cuerpo. Para algunas peticiones (métodos distintos de GET, HEAD y POST simples, o cabeceras propias) el navegador pregunta antes con una petición previa OPTIONS.

Lo importante para el informe: CORS no impide que la petición llegue al servidor. Decide si el código de otro sitio puede leer lo que vuelve. Por eso no sustituye la protección contra las peticiones forzadas entre sitios (CSRF): una petición simple, de las que no llevan consulta previa, se ejecuta en el servidor aunque la política no deje leer su respuesta.

Con cookies de por medio entran dos cabeceras. La petición tiene que ir con credenciales y la respuesta tiene que traer Access-Control-Allow-Credentials: true. Además, el estándar de Fetch no acepta el comodín en ese caso: si la petición lleva credenciales y la respuesta dice Access-Control-Allow-Origin: *, el navegador no entrega el cuerpo. Por eso un * en una API pública casi nunca es hallazgo: sirve para datos que cualquiera puede ver.

El fallo típico es otro. Para «soportar varios dominios» el servidor copia en Access-Control-Allow-Origin lo que llegue en Origin y añade las credenciales. El resultado es que cualquier sitio que visite una persona con la sesión abierta puede leer, con la cookie de esa persona, lo que la API le devuelve a ella. Falta una condición para que eso ocurra: que la cookie de sesión viaje en una petición entre sitios, cosa que solo hace si está marcada SameSite=None.

Abre el laboratorio, lee cors-pruebas.txt y después cookies.txt.

Hay contextos en los que el navegador manda Origin: null: documentos abiertos desde un archivo local, ciertas redirecciones y los marcos con atributo de aislamiento. Algunos equipos ponen null en su lista de permitidos «para que funcione el entorno local». El problema es que cualquiera puede fabricar un contexto que envíe ese valor, así que permitir null con credenciales equivale, en la práctica, a permitir a todo el mundo.

En la misma exportación hay un endpoint que rechaza el origen del evaluador pero acepta el nulo. Fíjate en qué devuelve.

La API de socios también refleja el origen y también dice true en las credenciales. Antes de copiar el mismo hallazgo, mira cómo se autentica. El navegador adjunta solo las cookies; una cabecera Authorization con un token la tiene que poner el propio código de la página, y el código de otro sitio no conoce ese token.

P-07 muestra una tercera forma de fallar: la regla acepta cualquier origen que empiece por el nombre del sitio, y https://www.boletas-jerusalen.example.origen-evaluador.example es un dominio del evaluador, no de Jerusalén. Las comprobaciones con «empieza por», «termina en» o «contiene» se saltan registrando un nombre que cumpla el patrón. La corrección se escribe para los tres casos a la vez.