CORS para APIs

IRC-Mania Die Seite rund um Sicherheit und Programmierung

Internet, Sicherheit , Internet Relay Chat

Gesponsert

CORS permite el acceso controlado a recursos a través de límites de dominio, pero debe configurarse correctamente para evitar riesgos de seguridad.

Descripción compacta

CORS es el acrónimo de Cross-Origin Resource Sharing, un mecanismo que permite a los navegadores solicitar recursos desde un dominio diferente al de la página web actual. Por defecto, el navegador bloquea estas solicitudes entre orígenes para proteger contra acceso no autorizado a datos. CORS habilita a los servidores a especificar explícitamente qué orígenes, métodos y headers están permitidos. Una configuración CORS correcta es esencial para APIs consumidas por aplicaciones web. Al mismo tiempo, una configuración demasiado permisiva introduce riesgos de seguridad al permitir ataques entre orígenes. Los conceptos clave incluyen el header Origin, Preflight Requests, Access-Control headers y la distinción entre solicitudes simples y complejas.

Componentes importantes

Same-Origin Policy

La Same-Origin Policy es un mecanismo de seguridad fundamental en el navegador que impide que una página web acceda a datos de otro dominio. El origen se define por protocolo, dominio y puerto. Subdominios diferentes o puertos distintos se consideran orígenes diferentes.

Origin Header

El navegador envía un header Origin en solicitudes entre orígenes, indicando el dominio de origen. El servidor decide si permite la solicitud basándose en este header. Responde con Access-Control-Allow-Origin y otros headers CORS.

Access-Control-Allow-Origin

Este header especifica qué orígenes pueden acceder al recurso. Puede contener un dominio específico como https://app.example.com o un asterisco para todos los dominios. Los comodines deben evitarse en APIs con autenticación o datos sensibles.

Access-Control-Allow-Methods

Este header lista los métodos HTTP permitidos para solicitudes entre orígenes, como GET, POST, PUT, DELETE. El navegador solo puede usar los métodos explícitamente permitidos.

Access-Control-Allow-Headers

Este header indica qué headers adicionales el cliente puede enviar en la solicitud. Los headers estándar como Content-Type, Accept o Authorization deben permitirse explícitamente cuando son personalizados.

Access-Control-Allow-Credentials

Este header permite la transmisión de cookies, autenticación HTTP o certificados de cliente en solicitudes entre orígenes. Si se establece en true, Access-Control-Allow-Origin no puede ser un asterisco, debe especificar un dominio concreto.

Preflight Request

Para solicitudes complejas entre orígenes, el navegador primero envía una solicitud OPTIONS, el Preflight. El servidor responde con los métodos, headers y orígenes permitidos. Solo después el navegador envía la solicitud real. Los Preflight se disparan para métodos como PUT, DELETE o cuando hay headers personalizados.

Solicitudes simples y complejas

Las solicitudes simples usan GET, HEAD o POST con ciertos Content-Types y headers estándar. No requieren Preflight. Las solicitudes complejas usan otros métodos, headers personalizados o Content-Types específicos y desencadenan un Preflight.

CORS y riesgos de seguridad

Configuraciones CORS incorrectas pueden llevar a acceso no autorizado. Son particularmente peligrosas: Access-Control-Allow-Origin: * en APIs con Credentials, reflejar dinámicamente el header Origin sin validación, y permitir métodos inseguros. Los atacantes pueden explotar estos errores para robar datos en el navegador.

CORS en la configuración de API

CORS generalmente se configura en el API Gateway, servidor web o código de la aplicación. En Node.js se usa frecuentemente el paquete middleware cors, en Spring Boot existe @CrossOrigin, en ASP.NET Core UseCors. Independientemente de la tecnología, la configuración debe ser restrictiva y explícita.

Depuración de CORS

Los errores CORS en el navegador a menudo no muestran información detallada. Las herramientas de desarrollo del navegador y los logs de red ayudan a inspeccionar solicitudes Preflight y principales. Los logs del servidor deben registrar los headers Origin y las respuestas.

Ejemplo práctico

Una aplicación web en https://app.example.com accede a una API en https://api.example.com. La API debe permitir CORS para este origen.

El navegador envía la solicitud:

GET /api/v1/profile
Host: api.example.com
Origin: https://app.example.com
Authorization: Bearer TOKEN

El servidor responde con headers CORS:

HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Allow-Headers: Content-Type, Authorization

{
  "name": "Max Mustermann",
  "email": "max@example.com"
}

Para una solicitud PUT, el navegador primero envía un Preflight:

OPTIONS /api/v1/profile
Host: api.example.com
Origin: https://app.example.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: Content-Type, Authorization

El servidor responde al Preflight:

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Max-Age: 86400

Solo después el navegador envía la solicitud PUT real. De esta forma, CORS garantiza que solo orígenes autorizados accedan a la API.

IRC-Security.de

Cybersecurity Artikel und Tutorials

FAQ: CORS para APIs

Fuentes

1. https://developer.mozilla.org/docs/Web/HTTP/CORS
2. https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/11-Client-side_Testing/07-Testing_Cross_Origin_Resource_Sharing
3. https://fetch.spec.whatwg.org/#cors-protocol

Lecturas recomendadas sobre seguridad web

Si quieres profundizar en CORS, seguridad web y seguridad de APIs, te recomendamos los siguientes libros:

Premium VPS Hosting

Schnelle und sichere VPS Server

Gesponsert