Mala configuración de CORS (CORS misconfiguration)

Por defecto, un navegador deja que una página envíe ciertas peticiones a otro origen, pero no que lea las respuestas. CORS es el mecanismo con el que un servidor concede esa lectura, devolviendo Access-Control-Allow-Origin con un origen en el que confía. Para las peticiones que llevan cookies o credenciales, el servidor tiene que devolver además Access-Control-Allow-Credentials: true, y en ese caso el navegador rechaza el comodín: hay que nombrar el origen de forma explícita.

Esa restricción es la que lleva al fallo. Como una lista estática es incómoda, es habitual que las aplicaciones lean la cabecera de petición Origin y la devuelvan tal cual, lo que concede acceso a cualquier origen que pregunte. Combinado con credenciales, eso es un permiso general para que cualquier web de Internet lea respuestas autenticadas de la API usando la sesión del usuario que la visita.

La validación del origen se escribe como comparación de cadenas y la comparación está mal. Una comprobación por sufijo acepta un dominio del atacante que acabe en los mismos caracteres. Una comprobación por prefijo acepta un subdominio de algo que el atacante ha registrado. Una expresión regular con un separador sin escapar encaja con más de lo que se pretendía. Devolver el origen literal null, que producen los marcos aislados y algunas redirecciones, entrega el acceso a cualquier página capaz de generarlo.

El planteamiento que sale mal en los informes es llamar a CORS un control de seguridad de la API. No lo es. Es una instrucción para el navegador, y un cliente que no sea un navegador ignora todas estas cabeceras, así que una política permisiva no crea exposición frente a clientes programados y una política restrictiva no protege el endpoint de ellos. Importa exactamente cuando la credencial la adjunta un navegador de forma automática, y por eso a una API autenticada con un bearer token en una cabecera le afecta de forma distinta que a una autenticada con cookie. Confundir esa distinción es común en los informes de API. Y un subdominio hostil conseguido mediante subdomain takeover convierte un comodín por lo demás razonable sobre tu propio dominio en un exploit que funciona.

Enviamos peticiones con un origen que controlamos, con un subdominio del real, con una colisión de sufijo y con el origen null, y anotamos qué combinaciones devuelven una cabecera de permiso junto con credenciales. La prueba es una página en nuestro origen leyendo una respuesta autenticada, no la cabecera por sí sola, porque una cabecera permisiva en un endpoint que no devuelve nada sensible es una nota de higiene. El informe nombra el endpoint, los orígenes aceptados y el dato recuperado. Esto forma parte de cómo revisamos la exposición entre orígenes de una API.