Se o seu inventário de API não está atualizado, você não está vendo toda a superfície que pensa estar protegendo.
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.
Nossa abordagem
TR7 aplica API discovery junto com aprendizado de tráfego, schema positivo, limites de tamanho e profundidade e validação por campo.
Padrões de endpoint são extraídos do tráfego por path grouping
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.
O modelo de segurança positiva baseia-se no schema permitido
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 de tamanho, profundidade e contagem restringem o abuso
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 por campo verifica o formato dos dados
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.
Capacidades
O API Discovery & Schema transforma o inventário de endpoints aprendido em regras de segurança positiva aplicáveis.
Path grouping baseado em tráfego produz um inventário real de APIs
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.
A estrutura aprendida pode fluir para um schema, e um schema para regras, pelo fluxo OpenAPI
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.
Métodos permitidos aplicam uma allow-list de métodos por endpoint
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.
Allow-lists de headers e parâmetros de query reduzem a superfície de requisição
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.
Campos JSON, XML e de formulário são validados contra um schema positivo
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. SOAP é coberto pelo mesmo caminho: um envelope SOAP é XML, portanto a estrutura do envelope, o abuso do cabeçalho SOAPAction e construções hostis são inspecionados como XML — com assinaturas dedicadas à injeção de SOAPAction ao lado das verificações de esquema. AJAX também não exige mecanismo separado: uma chamada XHR ou fetch chega como corpo JSON ou de formulário e é validada exatamente nesses escopos.
Controles de tipo MIME bloqueiam tipos de conteúdo inesperados
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 de tamanho e profundidade reduzem o risco de payload excessivo
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.
Toggles Block JSON e Block XML restringem o tipo de corpo do endpoint
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.
Regex por campo valida o formato dos dados no nível do campo
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.
Recomendações de shadow API e endpoint zumbi são evidenciadas
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.
A detecção de desvio de schema captura mudanças no comportamento da API
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.
Relatórios de conformidade fortalecem a visibilidade de endpoints ativos
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.
Profundidade operacional
Os controles de discovery e schema de API operam nos escopos de path, query, header, formulário, JSON, XML e bruto.
Sete escopos de schema
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.
Variedade de tipos de regra
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.
Escopos de destino
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.
Estrutura de árvore de aprendizado
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.
Fluxo de recomendação e aprovação
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.
Análise de log em lote
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.
Quando usar
Detecção e visibilidade de shadow APIs
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.
Inventário de endpoints em um gateway de microsserviços
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.
Relatório de API ativo para auditoria de conformidade
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.
Captura de endpoints de teste deixados abertos em produção
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.
Perguntas frequentes
Como funciona o aprendizado de path grouping?
Como aparecem as recomendações de shadow API e endpoint zumbi?
Como funciona a integração com OpenAPI?
Como o modelo de segurança positiva difere da segurança negativa?
O que significa detecção de desvio de schema?
A quais campos se aplicam os limites de tamanho e profundidade?
Aprenda e proteja sua superfície de API a partir do tráfego real
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.