En esta guía práctica y profesional te explico cómo configurar correctamente las cabeceras CORS para permitir peticiones entre orígenes sin comprometer la seguridad. Cubriremos qué es CORS, las cabeceras clave, configuraciones recomendadas y técnicas para probar y depurar en producción. El objetivo es que implementes políticas claras y auditables que eviten errores comunes y vulnerabilidades.
¿Qué es CORS y por qué es importante?
CORS (Cross-Origin Resource Sharing) es un mecanismo del navegador que controla cómo los recursos de una web pueden ser solicitados desde un dominio distinto al origen del recurso, y su comportamiento está detallado en la documentación de MDN Web Docs. Entender CORS es crucial porque una configuración demasiado permisiva puede exponer datos sensibles, mientras que una configuración demasiado restrictiva puede romper integraciones legítimas. Los navegadores aplican CORS comprobando las cabeceras de respuesta y denegando solicitudes que no cumplan la política definida por el servidor.
Además de la práctica en navegadores, la especificación formal de CORS proporciona reglas sobre preflight, métodos y cabeceras admitidas, que se pueden revisar en el estándar de la W3C para comprender el flujo completo de solicitud-respuesta. Conocer estas reglas ayuda a diagnosticar por qué una petición está siendo bloqueada y a diseñar una política equilibrada entre disponibilidad y seguridad. Revisar las fuentes oficiales facilita justificar decisiones de configuración en entornos corporativos o de producción.
Cabeceras CORS esenciales y funciones
Las cabeceras fundamentales que manejarás son: Access-Control-Allow-Origin, Access-Control-Allow-Methods, Access-Control-Allow-Headers, Access-Control-Allow-Credentials y Access-Control-Max-Age, y la documentación de cada una se encuentra disponible en páginas como la de MDN. Cada cabecera cumple una función concreta: origen permitido, métodos permitidos, cabeceras personalizadas aceptadas, si se admiten cookies y cuánto tiempo cachear la respuesta de preflight. Identificar qué combinación necesita tu API evita sobreexponer recursos o provocar fallos en clientes legítimos.
Al diseñar una política, evita soluciones genéricas como usar "*" en Access-Control-Allow-Origin si tu aplicación usa credenciales, porque eso ignora límites importantes de seguridad. Además, configurar Access-Control-Max-Age de forma razonable puede reducir la carga de preflight en clientes, mejorando latencia sin sacrificar control. Mantén un inventario de endpoints y sus requisitos CORS para aplicar reglas específicas por ruta en lugar de políticas globales demasiado amplias.
Configurar Access-Control-Allow-Origin
Access-Control-Allow-Origin es la cabecera que indica qué orígenes pueden acceder a un recurso y se puede configurar con un valor específico o con "", aunque el uso de "" no es compatible con credenciales y suele ser inseguro en APIs privadas. Para ejemplos prácticos y la sintaxis recomendada, consulta la guía de MDN sobre Access-Control-Allow-Origin. Una buena práctica es reflejar dinámicamente el origen de la petición cuando se permite acceso solo a una lista blanca de dominios verificados.
En servidores web como NGINX y Apache puedes aplicar reglas por bloque de servidor o por ubicación para controlar esta cabecera de forma granular; en NGINX, el módulo de cabeceras permite añadir o modificar la respuesta según condiciones, como se describe en la documentación oficial de NGINX. Implementar una lista blanca y lógica de reflexión en la capa de aplicación también facilita auditorías y registro de accesos por origen. Asegúrate de registrar las decisiones y pruebas para poder reproducir y revisar la política en auditorías de seguridad.
Políticas seguras para métodos y credenciales
Definir Access-Control-Allow-Methods y Access-Control-Allow-Headers limita los métodos HTTP y las cabeceras personalizadas que aceptas, lo que reduce la superficie de ataque al bloquear acciones no necesarias para un endpoint concreto. Es recomendable especificar solo los métodos necesarios (por ejemplo, GET, POST) y enumerar las cabeceras personalizadas esperadas en vez de permitir cualquier cabecera. Esta práctica facilita el control de cambios y mejora la trazabilidad en caso de comportamiento inesperado.
Respecto a credenciales, Access-Control-Allow-Credentials debe habilitarse únicamente si confías en el origen y manejas cookies o cabeceras de autenticación, y su uso exige no emplear "*" en Allow-Origin; para más detalles sobre riesgos y comportamiento consulta el Cheatsheet de OWASP sobre CORS. También es esencial revisar la expiración de sesiones y políticas CSRF complementarias cuando aceptas credenciales desde otros orígenes. Mantener la mínima permisividad necesaria y combinar CORS con controles de autenticación robustos reduce considerablemente el riesgo.
Probar y depurar respuestas CORS en producción
Para diagnosticar CORS en producción, las herramientas del navegador son el primer recurso: la pestaña Red en DevTools muestra las cabeceras de request y response, los mensajes de error y si una petición fue bloqueada por CORS, como explica la documentación de Chrome DevTools. Reproducir las solicitudes con la misma cabecera Origin y observar las respuestas de preflight (OPTIONS) ayuda a identificar configuraciones faltantes o erróneas. Complementa con registros del servidor que muestren la lógica de decisión del origen y las cabeceras emitidas.
Herramientas de línea de comandos como curl permiten simular peticiones desde distintos orígenes usando la cabecera Origin y verificar la respuesta real del servidor, lo cual es útil para scripts de monitorización o pruebas automatizadas; la utilidad oficial de curl permite construir estas pruebas fácilmente. Integra pruebas de CORS en tu pipeline de CI/CD para detectar cambios que rompan integraciones antes de desplegar. Además, centraliza los logs de errores CORS para identificar patrones y orígenes problemáticos con rapidez.
Configurar cabeceras CORS correctamente implica conocer las cabeceras clave, aplicar políticas mínimas necesarias y probar sistemáticamente en entornos controlados y en producción. Siguiendo las prácticas recomendadas y apoyándote en documentación oficial, reducirás errores y mejorarás la seguridad y disponibilidad de tus APIs.