CORS (Cross-Origin Resource Sharing)

Qué es CORS (Cross-Origin Resource Sharing)

CORS (Cross-Origin Resource Sharing) es un mecanismo basado en encabezados HTTP que relaja de forma segura la política de mismo origen del navegador web, permitiendo el intercambio de recursos entre diferentes orígenes. Un origen se define por la combinación de tres elementos: esquema (http/https), nombre de host y número de puerto.

La política de mismo origen es un mecanismo de seguridad del navegador que restringe que los scripts cargados desde un origen accedan a recursos de otro origen. Sin esta restricción, un sitio malicioso podría llamar a la API de un sitio bancario donde el usuario ha iniciado sesión a través del navegador del usuario.

Sin embargo, en las aplicaciones web modernas, es común que el frontend y la API del backend operen en dominios diferentes. CORS permite la comunicación cross-origin necesaria de forma segura, ya que el servidor indica explícitamente "qué orígenes tienen permiso de acceso" mediante encabezados de respuesta HTTP.

Mecanismo de funcionamiento de CORS

CORS opera de dos maneras según el tipo de solicitud.

Solicitud simple (Simple Request)

Las solicitudes GET, HEAD y POST (limitadas a ciertos Content-Type) sin encabezados personalizados se tratan como "solicitudes simples". El navegador envía la solicitud directamente y verifica el encabezado Access-Control-Allow-Origin de la respuesta. Si es un origen permitido, pasa la respuesta a JavaScript; de lo contrario, la bloquea.

Solicitud preflight (Preflight Request)

Para solicitudes que no cumplen las condiciones de solicitud simple, como PUT, DELETE o solicitudes con encabezados personalizados, el navegador envía una "solicitud preflight" con el método OPTIONS antes de la solicitud real. El servidor responde con los siguientes encabezados indicando las condiciones de permiso.

• Access-Control-Allow-Origin: Orígenes permitidos
• Access-Control-Allow-Methods: Métodos HTTP permitidos
• Access-Control-Allow-Headers: Encabezados de solicitud permitidos
• Access-Control-Max-Age: Tiempo de caché del resultado preflight (segundos)

Si la respuesta preflight cumple las condiciones de permiso, el navegador envía la solicitud real.

Solicitudes con credenciales

Para solicitudes cross-origin que incluyen cookies o encabezados de autenticación, se requiere Access-Control-Allow-Credentials: true. En este caso, no se puede usar el comodín (*) en Access-Control-Allow-Origin y se debe especificar un origen concreto.

Errores de configuración comunes y riesgos de seguridad

Los errores de configuración de CORS invalidan la protección de la política de mismo origen y generan graves riesgos de seguridad.

• Uso indiscriminado de Access-Control-Allow-Origin: *: Permitir todos los orígenes hace que cualquier sitio pueda acceder a la API. No debe usarse excepto para API públicas. Nunca debe usarse en API que manejan credenciales.
• Reflejo sin validación del encabezado Origin: Una implementación que refleja directamente el valor del encabezado Origin de la solicitud en Access-Control-Allow-Origin es prácticamente igual a un comodín. Se debe validar con una lista blanca.
• Permitir origen null: Permitir Access-Control-Allow-Origin: null permite el acceso desde iframes sandboxed o archivos locales, lo que puede ser explotado para ataques.
• Permiso excesivo de subdominios: Si se permite con un patrón como *.example.com, si un atacante toma el control de un subdominio, puede explotar CORS.

Los errores de configuración de CORS pueden amplificar el daño cuando se combinan con XSS o CSRF.

Mejores prácticas para una configuración segura de CORS

Directrices para configurar CORS de forma segura.

• Gestionar los orígenes permitidos con lista blanca: Gestionar la lista de orígenes permitidos en variables de entorno o archivos de configuración, y verificar con coincidencia exacta contra el encabezado Origin de la solicitud.
• Permitir solo los métodos y encabezados mínimos necesarios: Enumerar solo los que realmente se utilizan en Access-Control-Allow-Methods y Access-Control-Allow-Headers.
• Aprovechar la caché de preflight: Configurar Access-Control-Max-Age adecuadamente para reducir la frecuencia de solicitudes preflight y mejorar el rendimiento.
• Manejar con cuidado las solicitudes con credenciales: Al configurar Access-Control-Allow-Credentials: true, restringir estrictamente los orígenes permitidos.
• Combinar con CSP y encabezados de seguridad: No depender solo de CORS, sino construir defensa multicapa combinando con otros encabezados de seguridad.
• Asumir HTTPS como requisito: No incluir orígenes HTTP en la lista de permitidos. Prevenir la falsificación de origen mediante ataques de intermediario.

CORS es un control del lado del navegador y no se aplica a la comunicación entre servidores ni a solicitudes desde herramientas de línea de comandos. No dependa solo de CORS; implemente siempre autenticación y autorización del lado del servidor.

Conceptos erróneos comunes

CORS es una función de seguridad que protege al servidor

CORS es un control del lado del navegador y no protege directamente al servidor. Las restricciones de CORS no se aplican a curl ni a la comunicación entre servidores. CORS es un mecanismo que protege a los usuarios del navegador y es una capa de medidas diferente a la autenticación y autorización del servidor.

Si aparece un error CORS, basta con resolverlo con el comodín (*)

El comodín permite el acceso desde todos los orígenes, lo que conlleva un alto riesgo de seguridad. No se puede usar con solicitudes que incluyen credenciales. La solución correcta es agregar solo los orígenes necesarios a la lista blanca.

Términos relacionados

Artículos relacionados