CORS - Intercambio de recursos entre orígenes
Lectura de 2 min aprox.
CORS (Cross-Origin Resource Sharing, intercambio de recursos entre orígenes) es un mecanismo de control de acceso para cuando un navegador envía una solicitud a un servidor de un origen diferente (una combinación de dominio, puerto y protocolo). Se publicó como recomendación del W3C en 2014 y actualmente lo implementan todos los navegadores principales. Hoy en día, como se ha generalizado la arquitectura de ejecutar el frontend y el backend de una aplicación web en dominios distintos, comprender y configurar correctamente CORS es una habilidad esencial para los desarrolladores web. También es un mecanismo de seguridad estrechamente relacionado con CSRF y XSS.
Relación con la política del mismo origen (SOP)
Para entender CORS, primero necesitas conocer la política del mismo origen (Same-Origin Policy, SOP). La SOP es un modelo de seguridad del navegador introducido en Netscape Navigator 2.0 en 1995, con la restricción de que «un script cargado desde un origen no puede acceder a los recursos de otro origen».
Sin la SOP, ataques como que un sitio malicioso llame a la API de un sitio bancario para obtener la información de la cuenta de un usuario tendrían éxito con facilidad. CORS es un mecanismo para relajar de forma segura esta restricción de la SOP. Al hacer que el servidor declare explícitamente «permito solicitudes desde este origen», habilita la comunicación legítima entre orígenes.
Cómo funciona la solicitud de comprobación previa (OPTIONS)
Antes de enviar una solicitud entre orígenes que cumpla ciertas condiciones, el navegador envía una «solicitud de comprobación previa» usando el método OPTIONS. Es un mecanismo para consultar de antemano con el servidor: «¿Aceptarás esta solicitud?».
Las condiciones que desencadenan una comprobación previa incluyen el uso de los métodos PUT / DELETE / PATCH, Content-Type: application/json y otras cabeceras personalizadas, y el envío de credenciales (cookies). Una solicitud GET sin cabeceras personalizadas se trata como una «solicitud simple» y se omite la comprobación previa.
Cabeceras de respuesta CORS principales
| Cabecera | Función | Advertencias |
|---|---|---|
| Access-Control-Allow-Origin | Especifica el origen permitido | El comodín (*) no puede usarse junto con solicitudes con credenciales |
| Access-Control-Allow-Methods | Enumera los métodos HTTP permitidos | Se devuelve en la respuesta de comprobación previa |
| Access-Control-Allow-Headers | Enumera las cabeceras de solicitud permitidas | Indica explícitamente cabeceras personalizadas como Authorization |
| Access-Control-Allow-Credentials | Permite enviar credenciales como cookies | Cuando es true, no se puede usar * en Allow-Origin |
| Access-Control-Max-Age | Segundos durante los que se almacena en caché el resultado de la comprobación previa | Si es demasiado largo, los cambios de configuración tardan en aplicarse |
Errores de configuración comunes y sus riesgos
Una configuración que permite todos los orígenes. Es apropiada para API públicas, pero si se aplica a una API que requiere autenticación, un sitio malicioso puede obtener los datos de un usuario. Como no puede combinarse con credenciales, no funciona en API que usan autenticación basada en cookies.
Una implementación que devuelve el valor de la cabecera Origin de la solicitud directamente en Allow-Origin. Esto permite efectivamente todos los orígenes, pero como puede combinarse con Credentials: true, es más peligroso que *.
Establecer Access-Control-Allow-Origin: null permite solicitudes desde iframes en sandbox y archivos locales. Se aprovecha en ataques en los que un atacante llama a una API desde dentro de un iframe.
La relación entre CORS y CSRF
CORS y CSRF se confunden con frecuencia, pero protegen contra cosas diferentes. CORS es un mecanismo mediante el cual el navegador controla la lectura de una respuesta; no bloquea el envío de la solicitud en sí (en el caso de una solicitud simple). Es decir, aunque configures CORS correctamente, puede que no impida el envío de solicitudes mediante un ataque CSRF. La mitigación de CSRF requiere una capa de defensa aparte, como el método de tokens o el atributo de cookie SameSite. Es importante la defensa en profundidad combinada con CSP y SSL/TLS.
En servicios que usan una clave de API, una mala configuración de CORS a veces puede provocar la filtración de la clave de API. Consulta también Seguridad de las extensiones del navegador, Buenas prácticas para la gestión de claves de API y la Lista de verificación de seguridad para startups.libros sobre seguridad de Web API (Amazon) son recomendables para aprender patrones de implementación.
¿Te resultó útil este artículo?