Django, muy usado en el desarrollo backend de España y Latinoamérica, no incluye soporte para CORS de forma nativa: hace falta instalar el paquete de terceros django-cors-headers y configurar CORS_ALLOWED_ORIGINS explícitamente. Un error habitual es dejar CORS_ALLOW_ALL_ORIGINS = True activo (heredado de una configuración de desarrollo) en producción, lo que abre la API a cualquier sitio que quiera consumirla desde el navegador de un usuario autenticado.
La política de mismo origen
Por defecto, los navegadores aplican la Same-Origin Policy: el código JavaScript de una página de un origen (dominio + esquema + puerto) no puede leer las respuestas de peticiones hechas a un origen distinto. Este es un mecanismo de seguridad fundamental que impide que un script malicioso en un sitio robe datos de otro sitio donde el usuario esté autenticado.
Cómo CORS relaja esa política
CORS (Cross-Origin Resource Sharing) es un conjunto de cabeceras HTTP con las que un servidor autoriza explícitamente a ciertos orígenes externos (o a todos) a leer sus respuestas. La cabecera clave es Access-Control-Allow-Origin, que indica qué dominios tienen permiso.
La trampa del wildcard combinado con credentials
Cuando una petición se envía con credentials: 'include' —necesario para mandar la cookie de sesión a una API en otro subdominio—, el navegador rechaza de plano una respuesta con Access-Control-Allow-Origin: *. La especificación prohíbe expresamente combinar un origen comodín con credenciales; el servidor debe devolver el origen exacto que hizo la petición.
Para qué se necesita esto
- Diagnosticar un error de CORS y entender exactamente qué cabeceras faltan en el servidor.
- Detectar una configuración de
django-cors-headersdemasiado permisiva antes de pasar a producción. - Entender la diferencia entre peticiones "simples" y peticiones preflight (OPTIONS).
CORS no protege el servidor de ataques
Es un error común pensar que CORS es una medida de seguridad del lado del servidor — en realidad, solo restringe lo que puede leer JavaScript en el navegador. Un atacante que use curl, Postman o un script backend directamente ignora por completo CORS, porque esas herramientas no aplican la política de mismo origen. CORS nunca debe sustituir a una autenticación y autorización reales en el servidor.