Imagine que você entra em uma loja, e ao tentar pedir um café, o atendente automaticamente te entrega as chaves do cofre, o estoque e o cadastro de todos os clientes. Sem pedir documento, sem perguntar quem você é. Essa analogia pode parecer absurda — mas é exatamente o que encontrei em um sistema web brasileiro no início de 2026.
Meu nome é Pedro Henrique, tenho 17 anos, sou de Curitiba (PR) e me dedico há algum tempo à pesquisa de segurança da informação de forma independente. Neste artigo, vou contar como identifiquei uma vulnerabilidade crítica, o que aprendi com esse processo e, mais importante, por que resolvi fazer a coisa certa.
O que é uma vulnerabilidade em sistemas web?
Antes de entrar na história, vale explicar um conceito básico: uma vulnerabilidade é uma falha em um software, configuração ou lógica de sistema que permite que alguém faça algo que não deveria. Pode ser acessar dados sigilosos, assumir o controle de uma conta alheia, ou — como neste caso — se tornar administrador de um sistema sem nenhuma permissão.
Vulnerabilidades assim existem em volume muito maior do que as pessoas imaginam. A maioria dos sites e aplicativos foi construída com foco em funcionalidade e agilidade, e a segurança frequentemente fica em segundo plano. Não por má-fé, mas por falta de tempo, conhecimento ou prioridade.
Como a pesquisa começou
Parte do meu trabalho como pesquisador é analisar sistemas web em busca de falhas que possam ser exploradas por agentes mal-intencionados. Faço isso de forma ética: sem acessar dados desnecessariamente, sem causar dano, e sempre com o objetivo de reportar ao responsável.
Ao analisar a estrutura de um site, percebi que a API pública expunha funções internas que deveriam estar restritas apenas ao servidor. Funções que, em um cenário ideal, nem deveriam existir de forma acessível externamente.
Fiz um teste direto — utilizando técnicas conhecidas na área. E o resultado foi surpreendente: em questão de minutos, com uma conta de usuário comum recém-criada, consegui escalar meu nível de acesso para administrador do sistema.
O que isso significava na prática?
A partir desse acesso, era tecnicamente possível:
Visualizar dados de todos os usuários cadastrados — incluindo informações pessoais e de contato;
Acessar o painel administrativo completo do site;
Ler e manipular configurações internas do sistema;
Comprometer a integridade dos dados armazenados na plataforma.
Em termos técnicos, o problema estava em funções de banco de dados expostas sem controle adequado de permissão — algo que, em boas práticas de segurança, nunca deveria chegar ao ambiente de produção. A falha permitia que qualquer usuário autenticado se tornasse administrador sem nenhuma verificação adicional de identidade ou autorização.
A decisão: reportar com responsabilidade
Quando você encontra uma falha desse tipo, tem basicamente três caminhos: ignorar, explorar ou reportar.
Ignorar seria irresponsável — a falha continuaria existindo e poderia ser descoberta por alguém com intenções piores. Explorar seria antiético e ilegal. Então só restava o terceiro caminho: o responsible disclosure, ou divulgação responsável.
Entrei em contato diretamente com o responsável pelo site, detalhei tecnicamente o problema, apresentei evidências e me coloquei à disposição para ajudar na correção. Não divulguei nada publicamente antes que a falha fosse corrigida. Não acessei dados além do necessário para demonstrar o impacto.
Esse processo é padrão na comunidade de segurança séria. Empresas como Google, Microsoft e Meta mantêm programas formais de recompensa (bug bounty) justamente para incentivar pesquisadores a agir dessa forma. No Brasil, essa cultura ainda está em desenvolvimento — mas está crescendo.
O que os donos de sites podem aprender com isso
Se você mantém um site, uma loja virtual ou qualquer sistema com cadastro de usuários, aqui vão alguns pontos práticos:
Audite as permissões da sua API. Funções que manipulam cargos, dados de usuários ou configurações do sistema devem ter controles rígidos de acesso.
Revise as políticas de segurança do banco de dados. Ferramentas modernas como Supabase oferecem Row Level Security (RLS) — use e configure corretamente.
Crie um canal de contato para reporte de vulnerabilidades. Um simples e-mail como
[email protected]já faz diferença. Pesquisadores que encontram falhas vão querer falar com você — facilite esse contato.Trate reportes de segurança com seriedade e rapidez. Uma falha reportada de boa fé é uma oportunidade de corrigir algo antes que cause dano real.
O que os usuários podem fazer
Do lado de quem usa serviços online:
Use senhas únicas e fortes em cada plataforma. Gerenciadores de senha como Bitwarden facilitam muito isso.
Ative a autenticação em dois fatores (2FA) sempre que disponível.
Desconfie de sites que coletam muitos dados sem uma política de privacidade clara.
Se suspeitar que seus dados foram expostos, troque senhas e monitore seus cadastros.
Por que vale a pena fazer do jeito certo
Poderia ter explorado essa falha. Não fiz. E não me arrependo nem um pouco.
A segurança digital não melhora com invasões silenciosas — melhora com pesquisadores que reportam, com empresas que ouvem, e com uma cultura de colaboração entre quem constrói sistemas e quem os testa. Cada falha corrigida é um passo real na direção de uma internet mais segura para todo mundo.
Aos 18 anos, ainda estou no começo da minha trajetória — mas já aprendi que reputação nessa área se constrói exatamente assim: fazendo a coisa certa, mesmo quando ninguém está olhando.
Pedro Henrique é pesquisador independente de segurança da informação, com foco em vulnerabilidades em aplicações web e APIs. Atua com testes de penetração e divulgação responsável de falhas em sistemas brasileiros. — disponível para consultorias e testes de penetração em sistemas web.
Nota editorial: A vulnerabilidade descrita neste artigo foi corrigida antes desta publicação. Os detalhes técnicos foram intencionalmente omitidos para não facilitar tentativas de replicação em outros sistemas.
