Las aplicaciones web modernas típicamente acceden a APIs que corren en diferentes dominios, subdominios o puertos. El navegador restringe este acceso mediante la política CORS. Si una API no devuelve las cabeceras Access-Control-Allow-* correctas, la solicitud es bloqueada por el navegador aunque se ejecute correctamente en el servidor. El resultado es una aplicación rota para el usuario y un error CORS difícil de diagnosticar para el equipo.
En la mayoría de las organizaciones, este problema se distribuye a los equipos de aplicación. Cada servicio define su Origin, Method, Header, Credentials y comportamiento Max-Age por separado dentro de su propia configuración del framework. A medida que crece el número de servicios, se vuelve inevitable que la misma política CORS acabe escrita de forma diferente en distintas aplicaciones.
La configuración CORS incorrecta también crea riesgos de seguridad. Durante el desarrollo, los Origins con wildcard se abren como solución rápida, se otorgan permisos demasiado amplios junto con credenciales, o el comportamiento de preflight se deja incompleto. Cuando esas configuraciones llegan a producción, la superficie de la API queda expuesta innecesariamente.
El enfoque correcto es gestionar la política CORS como una regla central de respuesta/solicitud. La lista de origins permitidos, las credenciales, los métodos permitidos, las cabeceras permitidas y la caché de preflight deben definirse en un solo lugar y no dispersarse en el código de la aplicación.
La Regla de Política CORS de TR7 ofrece este modelo: hace que las cabeceras CORS de preflight y de respuesta real sean manejables desde una única acción, al nivel de vService o ruta.
La política CORS de TR7 reúne la validación de origen, la gestión de preflight, las cabeceras de respuesta y la lógica de aplicación condicional bajo una única regla.
TR7 puede comparar el valor de Origin entrante con una lista de permitidos definida. La lista puede contener dominios fijos o coincidencias más flexibles basadas en regex.
TR7 puede generar las cabeceras CORS requeridas para las solicitudes de preflight OPTIONS. Esto permite que la aplicación se centre solo en la solicitud real de la API.
Cabeceras como Access-Control-Allow-Origin, Allow-Methods, Allow-Headers, Allow-Credentials y Max-Age se agregan a través de la política central. La compatibilidad del navegador se vuelve independiente del código de la aplicación.
Diferentes superficies de API en el mismo dispositivo pueden operar con diferente comportamiento CORS. La API pública puede ser más amplia, la API de socios más estrecha y la API interna gestionada con su propia lista de permitidos.
La Regla de Política CORS simplifica el proceso de publicación de APIs proporcionando gestión de preflight y respuesta real desde una única acción.
La acción CORS de TR7 puede manejar tanto las solicitudes de preflight OPTIONS como las cabeceras de respuesta real de la API bajo la misma política. Esto evita que los equipos de aplicación codifiquen por separado el comportamiento de preflight y de respuesta real. La política se define una vez y se aplica al vService o ruta relevante. Las operaciones pueden gestionar el comportamiento CORS de forma centralizada.
Los valores de Origin permitidos pueden definirse explícitamente en la política CORS. Esta lista puede consistir en dominios específicos, patrones de subdominio o coincidencias basadas en regex. Se otorga acceso a aplicaciones de frontend de confianza sin verse obligado a usar wildcards. Se proporciona acceso al navegador sin exponer innecesariamente la superficie de la API a fuentes no deseadas.
Las organizaciones frecuentemente usan estructuras de subdominio basadas en clientes, tenants o entornos. La coincidencia de origen basada en regex permite establecer una política de permisos controlada sin escribir cada subdominio individualmente. Por ejemplo, los frontends de tenants bajo un árbol de dominio específico pueden aceptarse. Esta flexibilidad permite una gestión CORS escalable sin abrir wildcards.
El comportamiento de Access-Control-Allow-Credentials puede activarse o desactivarse de forma centralizada. Este ajuste es crítico para los frontends que trabajan con cookies o cabeceras de autorización. Cuando las credenciales están habilitadas, la lista de origins permitidos debe mantenerse estrecha. TR7 extrae este comportamiento de la configuración dispersa de los equipos de aplicación y lo lleva a un único punto de política.
Los métodos como GET, POST, PUT, PATCH, DELETE u OPTIONS pueden definirse dentro de la política. El navegador acepta solo los métodos permitidos durante el preflight. Esto aclara qué tipos de operaciones expone la API al lado del cliente. La seguridad y la experiencia del desarrollador se gestionan desde la misma lista.
Authorization, Content-Type, X-Request-ID u otras cabeceras de aplicación personalizadas pueden definirse en la lista de permitidos. El navegador comprueba durante una solicitud de preflight si estas cabeceras pueden usarse. Los permisos de cabeceras faltantes generan errores en el frontend; los permisos de cabeceras demasiado amplios crean una exposición de superficie innecesaria. TR7 gestiona este equilibrio de forma centralizada.
El valor Access-Control-Max-Age controla cuánto tiempo el navegador almacena en caché el resultado del preflight. Un valor max-age apropiado reduce el tráfico OPTIONS para llamadas frecuentes a la API. Un valor demasiado corto genera sobrecarga innecesaria de preflight; uno demasiado largo puede significar que los cambios de política se reflejen tarde. TR7 hace que este ajuste sea configurable por necesidad del servicio.
Cada vService puede tener su propia política CORS. La API pública, la API de socios, la API de administración o la API interna pueden operar con diferentes listas de origen y métodos. Este modelo evita que una única configuración CORS global se aplique de forma demasiado amplia a todas las APIs. El operador establece límites de seguridad por servicio.
Se pueden aplicar diferentes políticas CORS a diferentes rutas dentro del mismo vService. Por ejemplo, `/public/api` puede operar con una lista de origen más amplia mientras que `/admin/api` opera solo con un frontend de gestión específico. Esto separa la superficie de la API a nivel de endpoint. No es necesario escribir complejos bloques if de CORS en el código de la aplicación.
La acción CORS puede usarse como parte del motor de reglas de tráfico. Las cabeceras CORS pueden aplicarse basándose en condiciones de host, ruta, cabecera, método u otras condiciones. Esto permite gestionar muchos modelos de publicación diferentes en un único dispositivo. La política CORS se convierte en una regla de tráfico consciente del contexto en lugar de una configuración estática.
Cuando el comportamiento CORS se distribuye entre los frameworks de la aplicación, cada lenguaje y servicio requiere diferente lógica de configuración. TR7 lleva este comportamiento a la capa ADC, reduciendo la dependencia de la aplicación. Los equipos de aplicación se centran solo en la lógica de negocio de la API mientras el estándar CORS se mantiene centralmente. Los servicios legacy y modernos pueden publicarse bajo el mismo modelo de política.
Cuando la política CORS se cambia dentro de la configuración central, puede incluirse en los procesos de auditoría y reversión. Las preguntas de quién abrió qué Origin, qué método o qué comportamiento de credenciales pueden rastrearse. Esto es especialmente importante durante las revisiones de seguridad. La gestión CORS auditable reemplaza la configuración dispersa de las aplicaciones.
La Regla de Política CORS opera junto con la coincidencia de origen, el comportamiento de credenciales, la respuesta de preflight, el equilibrio de max-age, el alcance de ruta y la visibilidad de auditoría.
El valor de Origin entrante puede compararse con una lista de permitidos o reglas regex. Si no hay coincidencia, las cabeceras CORS pueden no agregarse, o puede aplicarse un comportamiento de rechazo según lo requiera la política. Se recomienda el uso de una lista explícita en lugar de un wildcard.
Cuando las credenciales están activas, la información de identidad como cookies y cabeceras de autenticación puede usarse en solicitudes cross-origin. En este modo es importante que la política de Origin sea estrecha y bien definida. Las credenciales junto con un Origin wildcard no son una suposición segura.
El navegador envía solicitudes OPTIONS para verificar los permisos de métodos y cabeceras. TR7 puede gestionar centralmente la respuesta de preflight generando las cabeceras Allow-* requeridas. Esto reduce la carga que recae sobre el servicio backend por el tráfico OPTIONS innecesario.
La duración de la caché de preflight requiere un equilibrio entre rendimiento y actualidad de la política. Una duración mayor produce menos solicitudes OPTIONS, pero los cambios CORS pueden sentirse tarde debido al caché del navegador. Este valor debe elegirse con cuidado para las APIs críticas.
La política CORS puede vincularse a condiciones específicas de ruta o host. Esto permite aplicar diferente comportamiento CORS a diferentes superficies de API dentro del mismo vService. Los endpoints de administración y los endpoints públicos no necesitan compartir los mismos permisos.
Los cambios de política CORS pueden rastrearse dentro de la configuración central y el proceso de auditoría. Los cambios en la lista de Origin o en el comportamiento de credenciales deben considerarse significativos desde el punto de vista de la seguridad. El historial de cambios tiene valor para la reversión y el cumplimiento.
Cuando una aplicación frontend accede a una API en un dominio diferente, el navegador puede recibir un error CORS. Agregar la política correcta de Origin, método y cabecera a través de TR7 resuelve el problema de forma centralizada.
En un entorno SaaS, cada tenant puede ejecutar su propio frontend en un subdominio dedicado. Una lista de permitidos con soporte regex acepta de forma controlada todo el árbol de dominios del tenant.
Las aplicaciones de socios pueden acceder a la API solo con Origins específicos y cabeceras de Authorization. La regla CORS de TR7 define estos permisos centralmente y cierra la superficie innecesaria de cabeceras y métodos.
Pueden requerirse cookies cross-origin en flujos SSO o de federación. TR7 pone este comportamiento bajo control con el toggle de credenciales y una lista de Origin estrecha.
Dentro del mismo vService, el endpoint público puede operar con una política CORS más amplia y el endpoint de administración con una más estrecha. Esta separación se aplica mediante una regla de tráfico sin escribirla en el código de la aplicación.
Gestione el preflight, las cabeceras de respuesta, la lista de origins permitidos y el comportamiento de credenciales desde una única regla ADC. Revisemos juntos una configuración en vivo en sus propios servicios.