Na maioria das organizações, o inventário de API fica na documentação da aplicação, em arquivos de schema desatualizados ou em listas mantidas por equipes individuais. Mas as aplicações mudam a cada release: novos endpoints são adicionados, os antigos são esquecidos, paths de teste ficam em produção. As equipes de segurança geralmente descobrem quais APIs estão ativas no tráfego real depois das equipes de aplicação.
Essa lacuna amplifica o risco de shadow API e endpoint zumbi. Um endpoint não documentado pode estar completamente fora da política WAF; um endpoint que não deveria mais estar em uso ainda pode ser acessível. Do ponto de vista de um atacante, essas áreas têm baixa visibilidade, proteção fraca e valem a pena ser sondadas.
Confiar exclusivamente em um arquivo de schema fornecido externamente também é insuficiente. Se o schema não estiver atualizado, não corresponderá ao tráfego real. A equipe de aplicação pode ter alterado um endpoint sem atualizar o schema, ou um path que nunca aparece no schema pode estar rodando em produção. Nesse caso, a política de proteção baseia-se em uma suposição desatualizada, não no comportamento real da aplicação.
O modelo de segurança negativa tradicional não resolve esse problema sozinho. Bloquear padrões de ataque conhecidos é importante, mas a verdadeira força na segurança de API é definir explicitamente os métodos, headers, parâmetros, tipos MIME e campos de corpo permitidos. Sem segurança positiva, requisições maliciosas desconhecidas mas aparentemente válidas podem passar sem desafio.
O TR7 API Discovery & Schema fecha essa lacuna: aprende o comportamento da API a partir do tráfego real, suporta a geração de schema pelo fluxo OpenAPI ou a geração de regras a partir de um schema, e coloca os controles de segurança positiva inline.
TR7 aplica API discovery junto com aprendizado de tráfego, schema positivo, limites de tamanho e profundidade e validação por campo.
TR7 pode aprender o comportamento de paths e métodos a partir do tráfego real e construir padrões de endpoint. Paths contendo IDs variáveis, datas ou tokens são normalizados em um inventário de API mais legível.
Allow-lists podem ser definidas para métodos, headers, parâmetros de query, chaves JSON, elementos XML, campos de formulário e tipos MIME. Em vez de apenas buscar padrões maliciosos conhecidos, a política declara explicitamente o comportamento esperado da API.
Limites como comprimento de path, profundidade de path, contagem de headers, contagem de queries, profundidade JSON, profundidade XML e tamanho bruto do corpo podem ser aplicados. Esses limites garantem que requisições excessivamente grandes ou complexas sejam verificadas antes de chegar ao backend.
Validação de regex pode ser definida para cada header, parâmetro de query, campo de formulário ou campo de corpo. Formatos de e-mail, telefone, ID, código de país ou específicos do serviço são verificados no nível do campo.
O API Discovery & Schema transforma o inventário de endpoints aprendido em regras de segurança positiva aplicáveis.
TR7 pode analisar informações de path e método de requisições de entrada para derivar padrões de endpoint. Paths como `/api/users/123` e `/api/users/456` podem ser agrupados sob um único padrão lógico. Essa abordagem torna visíveis endpoints que não estão na documentação, mas estão ativamente rodando em produção. O inventário de API baseia-se no comportamento real do tráfego, não em suposições.
TR7 está posicionado para suportar um fluxo de geração de schemas compatíveis com OpenAPI a partir do comportamento de API aprendido. Na direção inversa, regras TR7 podem ser geradas a partir de um schema OpenAPI fornecido pelo usuário. Esse modelo bidirecional reduz a lacuna entre o tráfego real e o contrato de API documentado. O operador usa a mesma plataforma tanto para discovery quanto para enforcement.
A lista de métodos permitidos — GET, POST, PUT, DELETE, PATCH e outros — pode ser definida por endpoint. Se um POST for enviado a um endpoint que só espera GET, por exemplo, esse comportamento pode ser tratado como violação de política. Uma allow-list baseada em métodos é uma camada de segurança positiva simples mas eficaz. Comportamento incorreto ou abusivo no endpoint é detectado mais cedo.
Headers e parâmetros de query permitidos podem ser definidos por endpoint. Para cada campo, um nome, formato de valor e validação de regex podem ser aplicados. Headers ou parâmetros inesperados podem ser vinculados a uma pontuação de segurança, alerta ou bloqueio. Dados fora do contrato de API não são passados ao backend sem verificação.
TR7 pode construir allow-lists no nível de chave JSON, elemento XML e campo de formulário. Campos obrigatórios podem ser definidos com mustArgs; campos desconhecidos podem ser excluídos da lista permitida. Essa estrutura descreve o corpo de requisição esperado em vez de apenas buscar assinaturas de ataque. Endpoints de API são protegidos de uma forma que se mantém mais próxima do seu próprio contrato.
Allow-lists para tipos MIME permitidos podem ser definidas para formulário e corpo bruto. Enviar dados a um endpoint que espera JSON com um tipo de conteúdo diferente pode ser tratado como violação de política. Esse controle é especialmente importante para APIs de upload de arquivo ou baseadas em formulário. O tipo de conteúdo torna-se uma entrada direta para a decisão de segurança.
Limites gerais de tamanho podem ser aplicados para headers, query strings, formulários, JSON, XML e corpo bruto. Controles de profundidade de aninhamento JSON e XML impedem que payloads excessivamente profundos adicionem carga ao parser e ao backend. Limites como contagem de chaves, contagem de valores, comprimento por campo e contagem de duplicatas também podem ser definidos. Esses controles criam um limite protetor tanto para segurança quanto para desempenho.
Alguns endpoints podem não precisar aceitar corpos JSON ou XML. TR7 pode fornecer controles para desabilitar completamente o uso de corpo JSON ou XML por endpoint. Isso impede que formatos de corpo inesperados cheguem ao backend. É particularmente eficaz para endpoints GET simples e serviços que não aceitam transações não baseadas em formulário.
Validação baseada em regex pode ser aplicada para cada header, parâmetro de query, campo de formulário ou campo de corpo. E-mail, telefone, UUID, ID numérico, código de país ou formatos específicos da organização são verificados dessa forma. Valores fora do formato não são deixados para a aplicação tratar — são capturados na borda. Esse modelo traz a dimensão de formato de dados do contrato de API para a política de segurança.
Endpoints aprendidos a partir do tráfego podem ser comparados com a lista de APIs documentadas existente. Endpoints ativos que não estão na documentação podem ser sinalizados como candidatos a shadow API; endpoints que não deveriam mais receber tráfego, mas ainda recebem, podem ser sinalizados como candidatos a endpoint zumbi. Essas recomendações são apresentadas como sugestões de aprendizado para revisão do operador, não como decisões de enforcement absoluto. As equipes de segurança podem mapear a superfície real de API mais rapidamente.
Com o tempo, novas chaves JSON, novos parâmetros de query ou uso diferente de métodos podem aparecer. TR7 pode tornar visíveis as diferenças entre o comportamento aprendido e a política de schema atual. Essas diferenças podem sinalizar uma mudança de versão de aplicação, um cliente com mau funcionamento ou uma tentativa de abuso. O operador pode aceitar a mudança e adicioná-la ao schema ou tratá-la como violação de política.
O API discovery ajuda a reportar quais endpoints estavam ativos durante um período específico. Perguntas como 'Quais endpoints receberam tráfego nos últimos 30 dias?' são importantes para equipes de segurança e conformidade. Um inventário baseado em tráfego fornece uma linha de base de auditoria mais realista do que um documento estático. A organização monitora sua superfície de API em relação ao comportamento ao vivo.
Os controles de discovery e schema de API operam nos escopos de path, query, header, formulário, JSON, XML e bruto.
Os controles de schema do TR7 cobrem campos de path, query, header, formulário, JSON, XML e brutos. Cada escopo pode ter seus próprios limites, allow-lists e regras de validação. A segurança de API é, portanto, definida por toda a superfície de requisição, não apenas pelo corpo.
Regras de schema podem ser definidas com diferentes tipos como complexInput, regex, numeric, boolean e enumSelect. Controles simples de on/off e listas detalhadas de campos são gerenciados dentro do mesmo DSL. O operador seleciona o tipo de regra com base no comportamento da API.
Regras podem ser aplicadas em diferentes níveis de destino: web application, api endpoint e application server. Isso permite uma distinção entre uma política de serviço geral e um schema específico para um único endpoint. Escolher o escopo correto produz uma política com menos repetição e uma área de efeito mais clara.
O modelo de aprendizado pode conter nós por path, contagens de frequência e informações de path filho. Informações resumidas podem ser extraídas por host ou grupo de serviço. Essa estrutura ajuda a entender quais partes da superfície de API têm alto tráfego, são esparsas ou estão aparecendo recentemente.
Alterações aprendidas podem ser submetidas para aprovação do administrador em vez de aplicadas automaticamente. O operador revisa propostas de novos endpoints, novos campos ou novos padrões e converte as apropriadas em política. Esse modelo posiciona o aprendizado como suporte à decisão guiada, não como automação descontrolada.
Arquivos de log históricos podem ser analisados em lote para derivar o comportamento da API retrospectivamente. Isso significa que o processo de discovery não está limitado apenas ao tráfego ao vivo. Períodos de tráfego anteriores, janelas de campanha ou momentos de incidente podem ser examinados separadamente.
As equipes de segurança podem comparar a lista de endpoints aprendida do tráfego real com a documentação de API existente. Paths ativos não presentes na documentação são levados para revisão como candidatos a shadow API.
As equipes de microsserviços podem ver o comportamento de endpoints de cada serviço a partir do tráfego sem esperar pela documentação manual. TR7 ajuda a transformar o inventário baseado em path e método em política de segurança.
As equipes de conformidade podem reportar quais endpoints estavam ativos durante um período específico. Isso torna a superfície de API que manipula dados mais claramente visível durante uma auditoria.
Se endpoints abertos para teste ou staging aparecerem no tráfego de produção, eles podem ser notados dentro das recomendações de aprendizado. A equipe de operações pode então fechá-los, restringi-los ou colocá-los sob a política de segurança correta.
Inventário de endpoints baseado em tráfego, visibilidade de shadow APIs e regras de schema positivo — vamos percorrer uma configuração ao vivo nos seus próprios serviços.