Aliases de host de API podem contornar sua revisão de destino?

Uma revisão de destino só tem valor quando analisa o nome que recebe a credencial. Se uma equipe aprova https://api.example.test, mas deixa agentes usarem livremente https://api-us.example.test, https://gateway.example.test ou um endpoint de compatibilidade fornecido pelo fornecedor, a aprovação descreve uma intenção, não um limite.

Já vi isso falhar da forma mais banal possível: alguém aprova um nome de host conhecido, uma variável de implantação aponta para um alias regional e o mesmo token bearer funciona. Ninguém precisou de um exploit dramático. A equipe simplesmente tinha mais nomes de destino do que o processo de revisão reconhecia.

A primeira correção é conceitual. Um registro CNAME, uma URL base alternativa, um redirecionamento, um endereço IP e uma autoridade HTTP estão relacionados, mas não são intercambiáveis. Tratá-los como se fossem a mesma coisa produz revisões que parecem cuidadosas e controles que vazam credenciais.

Uma revisão de destino cobre apenas o host literal

Uma revisão de api.example.test não aprova api-eu.example.test, proxy.example.test nem api.example.test.evil.invalid. A credencial deve ir apenas para um nome de host exato e normalizado que apareça em um inventário explícito daquela credencial.

As equipes costumam começar com uma regra informal como "este token é para a API da Example". Isso é uma declaração de propriedade, não uma regra de destino. Uma empresa pode operar muitos domínios, um fornecedor pode mover o tráfego por vários nomes e um terceiro pode hospedar parte da borda de um fornecedor. O cliente HTTP precisa de uma URL concreta. Seu controle também.

Defina o limite em termos que um parser de URL possa comparar:

• esquema: normalmente https
• nome de host: nome ASCII em minúsculas após o tratamento de IDNA
• porta: a porta explícita ou o padrão do esquema
• política de caminho: apenas se a credencial estiver limitada a uma superfície específica da API

Não substitua a lista de nomes de host por um teste de sufixo. endsWith("example.test") aceita notexample.test. endsWith(".example.test") ainda aceita todos os subdomínios atuais e futuros. Isso pode ser aceitável em uma malha de serviços interna, com um único proprietário e controles rígidos de emissão. Em geral, é descuido para uma credencial que pode alterar dados de produção.

A pergunta incômoda é se uma pessoa precisa aprovar cada nome de host antes do uso. Para um token com alto privilégio, sim. Para um token de escopo limitado usado com um fornecedor que publica muitos endpoints regionais, aprove uma lista mantida e faça de cada adição uma mudança deliberada. O custo de mais uma revisão é menor que o de explicar por que um token chegou a um nome de host que ninguém registrou.

Isso também separa o controle de destino da revisão do conteúdo da solicitação. Quem revisa pode aceitar um GET para um host aprovado e rejeitar um POST que altera cobranças. São questões diferentes. Não diga que uma verificação de host determina se a solicitação é segura. Ela determina para onde a credencial pode ir.

CNAMEs mudam a rota, não o host HTTP

Um CNAME altera a resolução de DNS. Por si só, ele não reescreve o nome de host na URL, o cabeçalho HTTP Host nem a indicação de nome de servidor TLS que um cliente HTTPS convencional envia.

Suponha que um agente chame esta URL:

https://api.example.test/v1/orders

O DNS pode responder:

api.example.test.  300  IN  CNAME  api.edge.vendor.test.
api.edge.vendor.test. 300 IN A      203.0.113.42

A conexão TCP chega a 203.0.113.42, talvez em uma infraestrutura operada pelo fornecedor. Ainda assim, o cliente deve pedir api.example.test no TLS e enviar Host: api.example.test. Se o servidor não apresentar um certificado válido para esse nome original, a validação do certificado deve falhar. Se apresentar, o servidor está autorizado a encerrar o tráfego para esse nome, pelo menos naquele momento.

Essa diferença importa porque derruba uma correção popular, mas errada: aprovar o destino do CNAME como se fosse a autoridade da API. O nome de destino é evidência de roteamento. Ele ajuda a entender para onde o tráfego vai, mas não substitui a revisão do nome de host da URL que recebe o cabeçalho de autorização.

A RFC 1034 descreve um CNAME como um alias para outro nome de domínio e exige que a busca continue no nome canônico. Isso explica o comportamento do resolvedor, não uma decisão sobre credenciais HTTP. O DNS não conhece tokens bearer, escopos de API nem sua aprovação de mudança.

Um CNAME se torna relevante para a segurança em quatro casos práticos:

1. O nome DNS pertence a outra equipe ou fornecedor, de modo que uma mudança de registro pode alterar onde sua autoridade aprovada encerra o tráfego.
2. O endereço resolvido entra em uma rede que você não esperaria, como uma faixa interna ou um endereço de metadados de nuvem.
3. Um controle aprova nomes da saída do DNS em vez da autoridade da URL e deixa uma relação de alias substituir uma decisão de autorização real.
4. O aplicativo constrói uma segunda URL a partir do nome resolvido, do destino de redirecionamento ou do resultado de descoberta de serviço e então encaminha credenciais.

O quarto caso vaza tokens. Os três primeiros enfraquecem a revisão e tornam vazamentos futuros mais prováveis. Eles exigem testes e responsáveis diferentes.

Um CNAME também não protege contra DNS rebinding. Se um nome de host permitido pelo cliente passar a resolver para outro endereço, o cliente poderá abrir uma nova conexão para esse endereço. Nos destinos que você controla, monitore os registros e limite para onde eles podem resolver. Nos destinos que você não controla, não suponha que uma única consulta DNS prova segurança permanente.

URLs base alternativas criam a forma mais discreta de contornar o controle

URLs base alternativas são a forma mais comum de contornar o controle, porque mudam diretamente a autoridade HTTP. São os nomes escondidos em variáveis de ambiente, padrões de SDK, fixtures de teste e notas de migração.

Um serviço pode documentar todas estas URLs por motivos legítimos:

https://api.example.test
https://api-us.example.test
https://sandbox-api.example.test
https://gateway.example.test/service-a
https://tenant-42.api.example.test

Hoje elas podem encerrar o tráfego na mesma borda. Isso não significa que merecem a mesma credencial. O endpoint de produção pode aceitar um token no nível da conta; o endpoint sandbox pode enviar solicitações para outro sistema; o caminho do gateway pode selecionar outro serviço; o nome de host do tenant pode rotear conforme a identidade do cliente. Os nomes codificam diferenças operacionais que uma comparação de IP esconde.

O padrão de falha é previsível. Uma base de código define API_BASE_URL com um padrão de produção. Uma pessoa desenvolvedora a altera para um teste regional ou uma migração. A camada que injeta credenciais vê uma URL que ainda parece relacionada e adiciona o cabeçalho. A revisão de destino estava associada a um rótulo como "API da Example", não à autoridade exata, e ninguém percebe a ampliação.

Corrija o modelo de dados antes de corrigir o código. Cada credencial precisa de seu próprio registro, com quatro campos que quem revisa possa inspecionar:

credential: orders-write-prod
allowed authorities:
  https://api.example.test:443
  https://api-us.example.test:443
purpose: create and amend production orders
owner: commerce operations
review trigger: DNS change, new endpoint, scope change

A palavra "autoridades" é proposital. Armazene juntos o esquema, o host e a porta. Um nome de host aceitável em HTTPS não fica aprovado automaticamente em uma porta fora do padrão. Um caminho pode importar quando um gateway compartilhado usa um host para APIs sem relação, embora regras de caminho precisem de normalização cuidadosa e jamais devam substituir credenciais separadas quando os escopos forem diferentes.

Não trate a lista publicada por um fornecedor como seu inventário final. A documentação do fornecedor mostra o que pode existir. Seu código e suas configurações de implantação mostram o que você pode chamar. Você precisa dos dois, além dos nomes que permanecem em automações antigas depois de uma migração.

O público da credencial é o limite

A pergunta correta não é "quais servidores pertencem a este fornecedor?". É "quais autoridades HTTP podem receber este segredo exato neste caminho de solicitação específico?".

Um token bearer não tem restrição de público embutida, a menos que o emissor a imponha. Assim que um cliente o coloca em um cabeçalho Authorization, todo destinatário que recebe o cabeçalho pode tentar usá-lo. A autenticação Basic e cabeçalhos personalizados de chave de API têm o mesmo problema de transporte. A criptografia de transporte protege a solicitação durante o trânsito, mas não restringe o público na camada de aplicação.

Tokens de acesso OAuth às vezes incluem uma claim aud. Isso ajuda o servidor de recursos a rejeitar um token destinado a outra parte, mas não confunda rejeição no lado do servidor com comportamento seguro do cliente. Enviar um token ao nome de host errado ainda o expõe a esse host e o coloca nos logs de acesso, na telemetria ou na fila de incidentes dele. Um token rejeitado é melhor que um token aceito, mas a exposição continua evitável.

A vinculação de credenciais tem duas partes:

• O cliente injeta a credencial apenas para uma autoridade revisada.
• O emissor da credencial atribui a ela o escopo, o público e o ambiente mais restritos possíveis na prática.

Você precisa das duas. A vinculação a hosts evita que um erro do cliente espalhe um segredo por serviços vizinhos. O escopo limita o dano se o host esperado, seus logs ou sua configuração de rota forem comprometidos.

Por isso, uma única chave de API para toda a organização é um acordo tão ruim. Ela facilita a configuração e complica a resposta a incidentes. Se a mesma chave chega a uma API de pagamentos, um coletor de análises e um gateway de staging, você não consegue revogar o acesso a um destino sem interromper os três. Credenciais separadas transformam um erro de roteamento em uma rotação contida, em vez de uma indisponibilidade que mobiliza toda a equipe.

Faça o inventário de nomes a partir do código, do DNS e da documentação do fornecedor

Um inventário de endpoints se torna confiável quando registra o uso observado, não apenas a arquitetura planejada. Monte-o a partir do código, da configuração de implantação, do DNS e da documentação do fornecedor, depois concilie as diferenças.

Comece com uma busca no repositório por esquemas de URL e configurações de URL base. Inclua código da aplicação, scripts de shell, definições de CI, arquivos de exemplo, definições de infraestrutura e fixtures de teste. Registre cada nome de host, inclusive os que parecem obsoletos. Nomes antigos continuam perigosos quando um cron job ou um prompt de agente ainda os invoca.

Depois, resolva cada candidato pelo mesmo contexto de resolvedor que a máquina chamadora usa. No macOS ou em outro sistema Unix, uma inspeção básica é assim:

dig +noall +answer api.example.test CNAME A AAAA

Um formato de saída útil é:

api.example.test.       300 IN CNAME api.edge.vendor.test.
api.edge.vendor.test.    60 IN A     203.0.113.42
api.edge.vendor.test.    60 IN AAAA  2001:db8::42

Faça consultas separadas para CNAME, A e AAAA se o resolvedor não devolver toda a cadeia em uma resposta. Registre a data da consulta e o resolvedor usado, porque o DNS dividido pode dar respostas diferentes para um laptop, um executor de CI e um host de produção. Não copie o endereço IP resultante para uma lista de permissões permanente de uma API de internet. As bordas mudam de endereço com frequência. Registre-o como evidência da revisão e gere alertas para mudanças inesperadas.

Em seguida, crie uma tabela de inventário com uma linha por autoridade, não uma linha por fornecedor. Ela deve responder a estas perguntas sem precisar de uma reunião:

Não invente uma linha só porque um fornecedor tem um endpoint. Marque-o como não usado até que código, configuração ou uma migração aprovada precise dele. O inventário deve tornar visível uma capacidade acidental, não documentar toda possibilidade.

O Cheat Sheet de Prevenção de Server-Side Request Forgery da OWASP destaca algo relacionado: quando um aplicativo se comunica apenas com aplicações confiáveis identificadas, uma lista de permissões é viável, mas a validação de domínio por si só não resolve o comportamento do DNS. A orientação é voltada a SSRF, mas a lição operacional vale aqui. Uma lista de nomes de host só é forte quando você sabe quem mantém esses nomes, para onde eles resolvem e se alguém pode transformar um nome revisado em outra solicitação mais tarde.

Redirecionamentos precisam de revisão própria

Um redirecionamento é uma nova decisão de destino. Um cliente que segue redirecionamentos automaticamente pode sair de uma autoridade aprovada depois da primeira solicitação, e um cabeçalho de autorização não pode fazer esse percurso junto.

Para chamadas de API com credenciais, comece com os redirecionamentos desativados. Trate uma resposta 301, 302, 303, 307 ou 308 como algo que exige uma decisão explícita. Se a nova URL já estiver na lista exata de autoridades da credencial e o comportamento do método e do corpo for aceitável, faça uma solicitação separada para ela. Se não estiver listada, pare.

Os códigos de status não são intercambiáveis. Um 303 normalmente muda uma solicitação para GET; 307 e 308 preservam o método e o corpo da solicitação. Repetir automaticamente um POST com um cabeçalho de autorização traz mais consequências que um GET aparentemente inofensivo, principalmente quando o novo host é diferente.

Teste o comportamento da biblioteca HTTP específica que você usa. Alguns clientes removem cabeçalhos sensíveis em mudanças de host, outros preservam cabeçalhos em condições que talvez você não espere, e wrappers podem alterar os padrões. Um teste deve capturar a solicitação que chega a um segundo host controlado e confirmar que ela não recebeu a credencial nem uma cópia do corpo. Não tome o nome de uma biblioteca como prova da política de redirecionamento dela.

Um caminho de chamada seguro é simples de descrever:

1. Parse the requested URL.
2. Normalize and match its authority against the credential record.
3. Inject the credential only after that match.
4. Send one request with redirects disabled.
5. If a redirect arrives, parse and review the new authority before any new request.

Essa sequência também protege contra um erro mais sutil: injetar o cabeçalho em um cliente genérico antes de verificar o destino. Quando o código anexa um token a um objeto de solicitação reutilizável, mudanças posteriores na URL podem levá-lo a um lugar não pretendido. Vincule credenciais no último momento responsável, depois de conhecer a URL final.

Hosts compartilhados exigem credenciais separadas

Um único nome de host pode hospedar várias APIs, ambientes e tenants. A correspondência exata de host é necessária, mas não consegue expressar todas as diferenças de segurança por trás de um gateway compartilhado.

Considere https://gateway.example.test. Um caminho pode criar faturas, outro enviar telemetria e um terceiro administrar usuários. Se um token bearer autoriza os três, uma revisão de host oferece apenas proteção ampla. Um erro que muda /telemetry para /admin permanece no nome de host aprovado e ainda funciona.

A resposta adequada costuma ser credenciais separadas com escopos distintos. Dê ao cliente de telemetria um token que não possa administrar usuários, mesmo que ambas as chamadas vão para o mesmo host. Se o fornecedor oferecer públicos ou indicadores de recurso, use-os. Se oferecer apenas tokens amplos, separe contas de serviço ou escolha um limite de integração mais seguro, em vez de fingir que uma lista de permissões por caminho resolve a autorização.

Regras de caminho ainda têm seu lugar. Elas podem detectar erros de programação e tornar a intenção revisável. Mas caminhos são mais fáceis de tratar incorretamente que hosts: codificação por porcentagem, barras repetidas, segmentos com ponto, reescritas de gateway e redirecionamentos de versão complicam a comparação. Normalize com o mesmo parser de URL e a mesma biblioteca de solicitações que envia a chamada. Nunca tome uma decisão de segurança com uma verificação de substring escrita à mão.

O mesmo raciocínio vale para portas. api.example.test:443 e api.example.test:8443 são autoridades diferentes. Um proxy reverso pode roteá-las para serviços distintos, e quem testa a segunda porta pode supor que a primeira revisão também a cobre. Registre ambas ou não permita nenhuma.

Coloque as aprovações onde uma pessoa ainda consegue avaliar o destino

Uma aprovação que diz apenas "permitir chamada de API" pede que a pessoa revisora assine um cheque em branco. O prompt precisa incluir o método, a autoridade completa normalizada, o caminho da solicitação, a identidade da credencial e o processo solicitante. Caso contrário, não há como perceber na prática que o agente mudou da API de produção para um nome de host de compatibilidade esquecido.

O Sallyport mantém a credencial no cofre criptografado e executa a ação HTTP, em vez de entregar o segredo ao agente. Isso é útil porque a aprovação pode ficar no limite da ação, onde o destino e o processo solicitante aparecem juntos.

Não transforme uma tela de aprovação em ritual. A aprovação por sessão funciona para uma execução de agente conhecida e breve, que chama um conjunto estável de autoridades aprovadas. Exija confirmação por chamada para credenciais que possam movimentar dinheiro, excluir dados ou acessar endpoints administrativos. O atrito deve acompanhar a consequência de uma chamada errada, não a paciência de quem revisa.

O Sallyport deliberadamente não tem linguagem de políticas nem mecanismo de regras, portanto não deve servir de desculpa para pular o inventário de endpoints. A barreira do cofre e os controles de autorização respondem se um processo pode usar uma credencial agora. O registro da credencial ainda precisa responder qual autoridade tem direito de recebê-la.

Os registros de atividade devem preservar evidências suficientes para reconstruir a decisão mais tarde: autoridade solicitada, rota resolvida quando disponível, método, status, sessão solicitante e qual registro de credencial se aplicou. Não registre o segredo nem payloads sensíveis completos apenas para melhorar uma trilha de auditoria. Um log que cria um segundo repositório de segredos não melhora a auditoria.

Revise aliases depois de cada mudança de DNS e integração

A vinculação de destino se deteriora quando mudam o DNS, os endpoints do fornecedor ou as configurações de implantação. Faça da revisão do inventário parte dessas mudanças, em vez de um exercício anual que descobre uma pilha de nomes desatualizados.

Acione uma revisão quando alguém adicionar ou editar um CNAME, alterar um registro A ou AAAA de um nome interno permitido, introduzir um endpoint regional, trocar um SDK, mudar um gateway de API ou adicionar um redirecionamento. Quem revisa deve comparar as listas antiga e nova de autoridades e decidir se a credencial existente pode acompanhar a mudança. Mudanças de propriedade do DNS merecem a mesma atenção que mudanças de propriedade do código.

Para nomes que você controla, gere alertas quando um nome de host aprovado passar a resolver para endereços privados, de loopback, link-local ou internos inesperados. Isso é uma defesa contra SSRF e contra vazamento de credenciais. Para nomes públicos de fornecedores, alerte sobre mudanças no destino de CNAME e mudanças relevantes nas faixas de endereços, depois investigue em vez de bloquear automaticamente toda rotação de CDN.

Mantenha um pequeno teste de regressão ao lado da integração. Ele deve tentar uma URL aprovada, uma URL base alternativa não listada, um host com sufixo enganoso, uma porta alternativa explícita e um redirecionamento entre hosts. O resultado esperado não é apenas uma conexão de rede que falha. O cliente precisa se recusar a anexar a credencial antes que qualquer solicitação alcance o destino não listado.

Essa última condição é o padrão que vale defender. Se o agente consegue enviar o segredo primeiro e descobrir depois que o destino estava errado, a revisão falhou quando mais importava.