Aplicações web modernas tipicamente acessam APIs rodando em domínios, subdomínios ou portas diferentes. O navegador restringe esse acesso por meio da política CORS. Se uma API não retornar os headers Access-Control-Allow-* corretos, a requisição é bloqueada pelo navegador mesmo que execute com sucesso no lado do servidor. O resultado é uma aplicação quebrada para o usuário e um erro CORS difícil de diagnosticar para a equipe.
Na maioria das organizações, esse problema é distribuído para as equipes de aplicação. Cada serviço define seu comportamento de Origin, Method, Header, Credentials e Max-Age separadamente em suas próprias configurações de framework. À medida que o número de serviços cresce, torna-se inevitável que a mesma política CORS acabe escrita de forma diferente em diferentes aplicações.
Configurações CORS incorretas também criam riscos de segurança. Durante o desenvolvimento, Origins com wildcard são abertas como correção rápida, permissões muito amplas são concedidas junto com credentials, ou o comportamento de preflight fica incompleto. Quando tais configurações chegam à produção, a superfície de API fica desnecessariamente exposta.
A abordagem correta é gerenciar a política CORS como uma regra central de resposta/requisição. A allow-list de Origin, credentials, métodos permitidos, headers permitidos e cache de preflight devem ser todos definidos em um único lugar e não espalhados pelo código da aplicação.
A TR7 CORS Policy Rule entrega esse modelo: torna os headers CORS de preflight e resposta real gerenciáveis a partir de uma única ação, no nível de vService ou path.
A política CORS do TR7 reúne validação de origin, gerenciamento de preflight, headers de resposta e lógica de aplicação condicional sob uma única regra.
O TR7 pode comparar o valor de Origin recebido com uma allow-list definida. A lista pode conter domínios fixos ou correspondências mais flexíveis baseadas em regex.
O TR7 pode gerar os headers CORS necessários para requisições OPTIONS de preflight. Isso permite que a aplicação se concentre apenas na requisição de API real.
Headers como Access-Control-Allow-Origin, Allow-Methods, Allow-Headers, Allow-Credentials e Max-Age são adicionados pela política central. A compatibilidade com o navegador torna-se independente do código da aplicação.
Diferentes superfícies de API no mesmo dispositivo podem operar com comportamento CORS diferente. A API pública pode ser mais ampla, a API de parceiro mais restrita e a API interna gerenciada com sua própria allow-list.
A CORS Policy Rule simplifica o processo de publicação de APIs fornecendo gerenciamento de preflight e resposta real a partir de uma única ação.
A ação CORS do TR7 pode tratar tanto as requisições OPTIONS de preflight quanto os headers de resposta de API real sob a mesma política. Isso impede que as equipes de aplicação codifiquem o comportamento de preflight e resposta real separadamente. A política é definida uma vez e aplicada ao vService ou path relevante. As operações podem gerenciar o comportamento CORS centralmente.
Os valores de Origin permitidos podem ser definidos explicitamente na política CORS. Essa lista pode consistir em domínios específicos, padrões de subdomínio ou correspondências baseadas em regex. O acesso é concedido a aplicações de frontend confiáveis sem ser forçado a usar wildcards. O acesso do navegador é fornecido sem expor desnecessariamente a superfície de API a origens indesejadas.
Organizações frequentemente usam estruturas de subdomínio baseadas em clientes, tenants ou ambientes. A correspondência de origin baseada em regex torna possível estabelecer uma política de permissão controlada sem escrever cada subdomínio individualmente. Por exemplo, frontends de tenant sob uma árvore de domínio específica podem ser aceitos. Essa flexibilidade habilita o gerenciamento CORS escalável sem abrir wildcards.
O comportamento de Access-Control-Allow-Credentials pode ser alternado centralmente. Essa configuração é crítica para frontends que trabalham com cookies ou headers de Authorization. Quando credentials estão habilitados, a allow-list de Origin deve ser mantida restrita. O TR7 move esse comportamento para fora das configurações dispersas das equipes de aplicação e para um único ponto de política.
Métodos como GET, POST, PUT, PATCH, DELETE ou OPTIONS podem ser definidos na política. O navegador aceita apenas os métodos permitidos durante o preflight. Isso esclarece quais tipos de operação a API expõe para o lado do cliente. Segurança e experiência do desenvolvedor são gerenciadas a partir da mesma lista.
Authorization, Content-Type, X-Request-ID ou headers de aplicação customizados podem ser definidos na allow-list. O navegador verifica durante uma requisição de preflight se esses headers podem ser usados. Permissões de header ausentes levam a erros de frontend; permissões de header muito amplas criam exposição desnecessária de superfície. O TR7 gerencia esse equilíbrio centralmente.
O valor Access-Control-Max-Age controla por quanto tempo o navegador armazena em cache o resultado do preflight. Um valor de max-age apropriado reduz o tráfego OPTIONS para chamadas frequentes de API. Um valor muito curto cria sobrecarga desnecessária de preflight; um muito longo significa que as alterações de política podem ser refletidas tarde. O TR7 torna essa configuração ajustável por necessidade de serviço.
Cada vService pode ter sua própria política CORS. A API pública, API de parceiro, API admin ou API interna podem operar com diferentes listas de origin e método. Esse modelo impede que uma única configuração CORS global seja aplicada de forma muito ampla a todas as APIs. O operador estabelece limites de segurança por serviço.
Diferentes políticas CORS podem ser aplicadas a diferentes paths dentro do mesmo vService. Por exemplo, `/public/api` pode operar com uma lista de origin mais ampla enquanto `/admin/api` opera apenas com um frontend de gerenciamento específico. Isso separa a superfície de API no nível de endpoint. Não há necessidade de escrever blocos if CORS complexos no código da aplicação.
A ação CORS pode ser usada como parte do motor de regras de tráfego. Os headers CORS podem ser aplicados com base em host, path, header, método ou outras condições. Isso permite que muitos modelos de publicação diferentes sejam gerenciados em um único dispositivo. A política CORS torna-se uma regra de tráfego consciente do contexto, em vez de uma configuração estática.
Quando o comportamento CORS é distribuído entre frameworks de aplicação, cada linguagem e serviço requer lógica de configuração diferente. O TR7 move esse comportamento para a camada ADC, reduzindo a dependência da aplicação. As equipes de aplicação se concentram apenas na lógica de negócio da API enquanto o padrão CORS é mantido centralmente. Serviços legados e modernos podem ser publicados sob o mesmo modelo de política.
Quando a política CORS é alterada na configuração central, pode ser incluída nos processos de auditoria e rollback. As perguntas sobre quem abriu qual Origin, qual método ou qual comportamento de credentials podem ser rastreadas. Isso é especialmente importante durante revisões de segurança. O gerenciamento CORS auditável substitui as configurações dispersas da aplicação.
A CORS Policy Rule é operada em conjunto com correspondência de origin, comportamento de credentials, resposta de preflight, equilíbrio de max-age, escopo de path e visibilidade de auditoria.
O valor de Origin recebido pode ser comparado com uma allow-list ou regras regex. Se não houver correspondência, os headers CORS podem não ser adicionados, ou um comportamento de rejeição pode ser aplicado conforme exigido pela política. Recomenda-se usar uma lista explícita em vez de um wildcard.
Quando credentials estão ativas, informações de identidade como cookies e headers de auth podem ser usadas em requisições cross-origin. Nesse modo é importante que a política de Origin seja restrita e bem definida. Credentials junto com uma Origin wildcard não é uma premissa segura.
Requisições OPTIONS são enviadas pelo navegador para verificar permissões de método e header. O TR7 pode gerenciar centralmente a resposta de preflight gerando os headers Allow-* necessários. Isso reduz a carga sobre o serviço de backend com sobrecarga desnecessária de OPTIONS.
A duração do cache de preflight requer um equilíbrio entre desempenho e atualidade da política. Uma duração maior produz menos requisições OPTIONS, mas as alterações CORS podem ser sentidas tarde devido ao cache do navegador. Esse valor deve ser escolhido cuidadosamente para APIs críticas.
A política CORS pode ser vinculada a condições específicas de path ou host. Isso permite que diferentes comportamentos CORS sejam aplicados a diferentes superfícies de API dentro do mesmo vService. Endpoints admin e endpoints públicos não precisam compartilhar as mesmas permissões.
As alterações na política CORS podem ser rastreadas no processo central de configuração e auditoria. As alterações na lista de Origin ou no comportamento de credentials devem ser consideradas significativas do ponto de vista de segurança. O histórico de alterações tem valor para rollback e fins de conformidade.
Quando uma aplicação frontend acessa uma API em um domínio diferente, o navegador pode receber um erro CORS. Adicionar a política correta de Origin, método e header pelo TR7 resolve o problema centralmente.
Em um ambiente SaaS, cada tenant pode rodar seu próprio frontend em um subdomínio dedicado. Uma allow-list com suporte a regex aceita toda a árvore de domínio do tenant de forma controlada.
Aplicações de parceiros podem acessar a API apenas com Origins e headers de Authorization específicos. A regra CORS do TR7 define essas permissões centralmente e fecha a superfície desnecessária de header e método.
Cookies cross-origin podem ser necessários em fluxos SSO ou de federação. O TR7 coloca esse comportamento sob controle com o toggle de credentials e uma lista restrita de Origin.
Dentro do mesmo vService, o endpoint público pode operar com uma política CORS mais ampla e o endpoint admin com uma mais restrita. Essa separação é aplicada por meio de uma regra de tráfego sem escrevê-la no código da aplicação.
Gerencie preflight, headers de resposta, allow-list de origin e comportamento de credentials a partir de uma única regra ADC. Vamos percorrer uma configuração ao vivo nos seus próprios serviços.