Durante años, muchos desarrolladores han visto CORS como un sistema de seguridad fundamental para el backend. Frases como “habilita CORS para que no te ataquen” o “bloquea dominios y estarás seguro” se repiten constantemente… pero son falsas.
En realidad, CORS no es un mecanismo de seguridad diseñado para proteger tu backend, ni evita que un atacante haga peticiones maliciosas. CORS es simplemente un control del navegador, no del servidor. En este artículo, desmontemos mitos y aclaremos qué hace (y qué no hace) realmente.
Qué es CORS (en realidad)
CORS significa Cross-Origin Resource Sharing. Su función principal es permitir que los navegadores decidan si pueden o no compartir recursos entre diferentes orígenes.
- El navegador es quien aplica CORS.
- El backend solo envía headers diciendo qué está permitido.
- Clientes fuera del navegador (Postman, cURL, apps móviles, scripts en servidores) ignoran completamente CORS.
Si un atacante quiere llamar tu API desde su propio servidor, puede hacerlo sin que CORS intervenga.
Mito: “CORS protege mi API de ataques externos”
Esto es completamente falso. CORS no detiene:
- Peticiones hechas desde servidores.
- Bots.
- Aplicaciones móviles.
- Scripts locales.
- Postman o cURL.
- Actores maliciosos con acceso a internet.
El error común: “Si bloqueo orígenes incorrectos en CORS, nadie podrá llamar mi API.” La verdad: Cualquier persona puede llamar tu API. CORS solo bloquea a páginas web cargadas en un navegador.
Mito: “Un origen permitido en CORS garantiza que la petición es segura”
Tampoco. Un atacante puede copiar tu frontend, montarlo en otro servidor y seguir llamando tu backend libremente. CORS no valida:
- Identidad del cliente.
- Autenticidad del sitio.
- Autorización o Tokens.
- Permisos.
CORS únicamente dice al navegador: “Si esta página intenta llamar a este backend, ¿le permitimos leer la respuesta?”. Nada más.
Entonces… ¿qué sí protege tu backend?
Para proteger realmente tu backend debes apoyarte en mecanismos de seguridad diseñados para detener ataques reales, no solo para controlar el comportamiento del navegador.
- Autenticación robusta: Tokens firmados (JWT), OAuth2, sesiones seguras, short-lived tokens y refresh tokens. Debes asegurarte de que cada petición provenga de un usuario o sistema debidamente identificado.
- Autorización basada en roles y permisos: No basta con saber quién es el usuario, sino definir qué puede hacer exactamente.
- Rate limiting: Controlar la frecuencia de las peticiones para evitar ataques de fuerza bruta o abuso de scrapers.
- Validación estricta de datos: Nunca confíes en la entrada del cliente. Toda entrada debe validarse y sanitizarse.
- Restricciones de IP (si aplica): Útil para APIs administrativas o internas.
- Logs, auditoría y monitoreo: Para detectar patrones anómalos e intentos de intrusión en tiempo real.
- Firewalls, WAF y reglas de seguridad: Herramientas que bloquean amenazas antes incluso de que lleguen a tu aplicación.
¿Por qué existe entonces CORS?
Su propósito real es proteger a los usuarios, no a los servidores. CORS evita que un sitio malicioso cargado en el navegador haga esto:
// Javascript
fetch("https://mitu-banco.com/api/transferencias", {
method: "POST",
body: JSON.stringify({ monto: 5000 }),
});…y lea la respuesta usando las cookies del usuario, sin que el usuario se dé cuenta. Es un control de privacidad, no un control de seguridad de servidores.
Ejemplo claro de confusión típica
Un desarrollador bloquea todo menos este dominio:
Access-Control-Allow-Origin: https://mi-frontend.com
Cree que nadie puede llamar su API desde otro lugar. Pero un atacante puede hacer:
curl -X POST https://mi-api.com/transferir -d '{"monto": 1000}'
Y lo hará sin restricciones porque cURL no respeta CORS. El backend aceptará la llamada si no tiene seguridad real.
Para resumir, las CORS no son una carta mágica que otorga seguridad infalible a tu servidor. Sigue implementándolas y configurándolas correctamente, pero recuerda que hay muchas otras capas de seguridad que no debes descuidar.
Un abrazo y hasta la próxima.