O Sentinel grava o tráfego real da sua aplicação, reexecuta cada requisição como se fosse outro usuário e prova, com evidência, onde a autorização falhou. Roda na sua infraestrutura. Operável por quem não é especialista.
As falhas mais caras em aplicações modernas não são injeção de SQL — são falhas de autorização. Um usuário acessa o registro de outro. Uma empresa enxerga os dados de outra empresa no mesmo sistema. Um usuário comum executa uma ação de administrador. Essas falhas lideram o OWASP API Security Top 10.
Para uma ferramenta comum, um HTTP 200 com o registro de um funcionário é sucesso. Ela não tem como saber que aquele funcionário pertence a outra empresa. Detectar isso exige entender a lógica de negócio.
Exige um pentester com Burp Suite fazendo trabalho manual, não repetível — e que expira no dia seguinte ao deploy. É por isso que quase ninguém testa autorização com a frequência necessária.
Navegue na sua aplicação logado como dois usuários diferentes e salve o tráfego. Pode ser pelo proxy do Sentinel, pelo DevTools do navegador ou pelo Burp.
Arraste os arquivos na tela do Sentinel e diga quem é quem. Nada de escrever script, configurar coleção de API ou descrever endpoints.
Um clique. O Sentinel reexecuta cada requisição como o outro usuário e como visitante anônimo, e compara as respostas.
O laudo mostra o que foi testado, o que falhou, a prova e o que fazer. Exporte em PDF. Não é uma lista de alertas — é uma lista de perguntas respondidas.
Um relatório que diz "possível vulnerabilidade" gera meses de debate. Um relatório que mostra a requisição feita com a identidade B e o dado de A voltando na resposta gera um ticket de correção.
Título e explicação em português, sem jargão. Se aparecer um termo técnico, a tradução vem colada.
Em uma frase: qual identidade foi trocada por qual, e o que se esperava que acontecesse.
A requisição exata e a resposta exata do servidor, com os segredos mascarados. A identidade aparece como rótulo, nunca como token.
Severidade, nível de confiança, classificação OWASP e CWE.
O que fazer para resolver, mais um resumo explicativo em português para quem não é da área.
Pronto para levar à diretoria, com evidência e detalhamento.
Cada requisição capturada roda três vezes: como o usuário original, como outro usuário e sem login nenhum. Se a resposta do usuário B contém o mesmo objeto que a de A, a autorização falhou — e o Sentinel guarda a prova.
| Achado | O que significa na prática | Gravidade |
|---|---|---|
| Acesso anônimo indevido | A operação respondeu sem nenhum login. | Alta |
| Acesso entre usuários | O usuário B viu o dado do usuário A, dentro da mesma empresa. É o que a literatura chama de IDOR / BOLA. | Alta |
| Vazamento entre empresas | Um usuário viu — ou alterou — dado de outra empresa no mesmo sistema. O isolamento entre clientes falhou. | Crítica |
| Escalonamento de privilégio | Um usuário comum acessou o que é exclusivo de um perfil privilegiado. | Alta |
Abre a aplicação em um navegador real sem interface, deixa o JavaScript rodar e observa o que ela guarda no armazenamento, o que monta em memória e o que dispara ao iniciar.
Aplicações compiladas — Flutter, por exemplo — não deixam nada legível no pacote entregue. Análise estática de 7 MB não revela nada; a credencial só aparece com a aplicação em execução.
O Sentinel reporta o tipo e o local da credencial — nunca o valor.
Quando você autoriza, o Sentinel reproduz a assinatura da requisição e reenvia. Se o servidor aceitar, está provado que a assinatura não protege nada. Vale também para corpo de requisição criptografado.
Ele obtém a credencial de assinatura sozinho: com a inspeção em tempo real ligada, observa a própria aplicação assinando e guarda o material criptografado. A credencial nunca é exibida — nem para quem opera o Sentinel.
E do próprio laudo o operador pode alterar o corpo da requisição — trocar o identificador do objeto, mudar o valor de um campo — e reenviar, reassinando automaticamente. Isso eleva o resultado de "B alcança o dado de A" para "B sobrescreve o dado de A com um valor arbitrário".
Sempre atrás de opt-in explícito, com perfil de administrador e registro de auditoria dedicado. Nada disso roda por padrão.
Em APIs GraphQL, o Sentinel consulta o esquema, descobre quais operações existem, monta consultas sozinho e roda o mesmo teste diferencial — sem nenhuma captura prévia.
Só gera operações de leitura. Nunca escreve, independentemente da configuração.
Suba o APK. O Sentinel extrai credenciais e endereços de servidor embutidos e verifica as configurações de segurança: tráfego sem criptografia, aplicativo depurável, backup permitido, componentes internos expostos.
O arquivo é analisado e descartado. Guarda-se apenas o resultado, criptografado.
O piso, feito bem: cabeçalhos de segurança, CORS, flags de cookie, métodos HTTP perigosos, versões expostas — mais rastros de erro, listagem de diretório, arquivos de versionamento acessíveis, documentação de API aberta em produção, backups esquecidos e mapas de código publicados.
Uma aplicação corporativa multiempresa: um app web moderno — compilado, sem código legível — conversando com uma API na nuvem. Vários clientes distintos no mesmo sistema.
O aplicativo assina suas requisições para a nuvem usando uma credencial permanente, disponível no navegador antes mesmo de qualquer login. A análise estática do pacote de 7 MB não revelava nada — a credencial só aparece com a aplicação em execução, e é exatamente ali que o Sentinel olhou.
O motor diferencial reexecutou uma operação de alteração de dados usando a identidade de outra empresa. O servidor aceitou. Falha comprovada com evidência crua — requisição e resposta.
Ele achou isso na primeira execução. Sem pentester.
Antes de qualquer texto ir para o modelo, uma barreira remove endereço, URL, IP, nome de empresa e segredos — verificada na entrada e na saída. O modelo recebe o padrão do problema, nunca o dado.
Credenciais são criptografadas em repouso e de escrita apenas: entram, são usadas pelo motor e nunca voltam para a tela, o laudo ou o log. Nem o operador vê a chave da própria empresa.
Nada que escreva no seu sistema roda sem uma autorização explícita e consciente do operador. As opções perigosas ficam recolhidas atrás de um aviso.
O Sentinel se recusa, por design, a alcançar redes internas e endereços privados. E roda inteiramente na sua infraestrutura, via Docker: tráfego, credenciais e laudos não saem da sua rede.
| DAST tradicional | Pentest manual com Burp | Sentinel | |
|---|---|---|---|
| Testa autorização entre usuários | Não | Sim | Sim |
| Precisa de especialista | Não | Sim | Não |
| Repetível a cada release | Sim | Não — custa caro toda vez | Sim |
| Entrega prova, não suspeita | Raramente | Sim | Sim |
| Dados ficam com o cliente | Depende — muitos são SaaS | Sim | Sim |
| Enxerga aplicação compilada em execução | Não | Manualmente | Sim |
Contra o DAST tradicional: Ele confere as fechaduras. O Sentinel testa as chaves.
Contra o pentest manual: O pentest te dá a resposta de terça-feira. O Sentinel te dá a resposta de hoje — e de novo no próximo deploy. Ele não substitui seu time de segurança: automatiza o trabalho repetitivo e caro, para o especialista cuidar do que exige criatividade.
39
Uma tela do Sentinel lista todas as validações que ele executa, com o que cada uma significa, qual o impacto e qual a severidade. Essa lista é gerada a partir do próprio motor de scan — ela não pode divergir do que o produto realmente faz.
O escopo é deliberadamente focado: autorização, credenciais no cliente, configuração e exposição de informação. Injeção de SQL, XSS e abuso de lógica de negócio estão no roadmap — não no produto de hoje.
O direito de rodar o Sentinel na infraestrutura da sua empresa, com tudo liberado. Um número, um ano, sem medidor.
Faixas por tamanho de empresa. A startup não paga como o banco, e nenhuma das duas é punida por testar mais.
Não existe versão SaaS do Sentinel: ele roda exclusivamente na infraestrutura da sua empresa, via Docker. É isso que garante que tráfego, credenciais e laudos não saem da sua rede — e a implantação nesse ambiente entra na conversa comercial junto com a licença.
Testar mais é o comportamento que queremos incentivar — não faz sentido cobrar por ele. Rode a cada deploy, em todos os ambientes, no dia em que suspeitar de algo. O laudo é o mesmo, ilimitado.
Não basta expor a vulnerabilidade. O Sentinel tem que conseguir testá-la sozinho.
Itens de roadmap, não funcionalidades disponíveis hoje.
Instalamos na sua infraestrutura, acompanhamos a primeira captura e entregamos o laudo completo. Nenhum dado sai da sua rede em nenhum momento.
Escolhemos juntos um alvo: site, API, painel ou app.
Docker no seu ambiente, duas capturas, um clique.
PDF em português, com evidência e correção.
O Sentinel usa credenciais. Ele nunca as mostra — nem para você.
