OWASP Top 10 sem jargão

Uma hora alguém te diz que o seu app precisa ser conferido contra o OWASP Top 10, e você concorda com a cabeça. Soa como um certificado que você não tirou. Não é. É uma lista, mantida por uma organização sem fins lucrativos, dos dez tipos de erro que continuam aparecendo em aplicação de verdade, ano após ano, em toda linguagem e em toda pilha de tecnologia.

Essa última parte é a que interessa. Não são ataques exóticos. São padrões, e é justamente por isso que uma lista de dez dá conta da maior parte do que dá errado.

As três que mais aparecem em app feito com IA

Esconder o botão não é trancar a porta. É o primeiro item da lista e o que a gente mais encontra. O seu app mostra o menu de administrador só pra administrador, e todo mundo supõe que isso resolveu. Só que o menu é o desenho, e o endereço atrás dele é a porta. Se o endereço continua respondendo quando uma conta comum pergunta, o app está conferindo do lado errado.

A segunda é configuração que ficou do jeito que veio. Regra que nunca foi ligada, página de teste ainda no ar, tela de depuração que imprime mais do que devia, mensagem de erro que diz o nome do banco. Nada disso foi escrito errado. Foi escrito pro primeiro dia e nunca mais revisitado. A versão mais comum dela em app feito com IA é a chave do banco escrita na página.

A terceira é confiar no que a pessoa digitou. Quando um texto que o visitante escreveu chega num lugar onde instrução é executada, o app não consegue distinguir um nome de uma ordem. É essa a ideia por trás de injeção, e agora ela tem uma prima moderna: o texto que chega num modelo de linguagem em vez de chegar no banco, que é alguém dando ordem pra IA do seu app.

A lista inteira, uma linha cada

• Controle de acesso quebrado: alguém alcança dado ou ação que era de outra pessoa.
• Falha de criptografia: dado sensível guardado ou enviado de um jeito que qualquer um que pegue consegue ler.
• Injeção: texto digitado pelo visitante acaba sendo tratado como instrução.
• Desenho inseguro: a funcionalidade em si não tem versão segura, por melhor que seja o código.
• Configuração insegura: padrão de fábrica, sobra e chave de depuração ainda ligados em produção.
• Componente vulnerável: uma biblioteca com buraco conhecido, ainda no seu app porque ninguém atualizou.
• Falha de autenticação: login fraco, código adivinhável, sessão que nunca termina de verdade.
• Falha de integridade: o seu app confia numa atualização ou num pacote que ele não tem como conferir.
• Falta de registro e monitoramento: alguma coisa acontece e nada em lugar nenhum anota.
• Requisição forjada pelo servidor: o seu servidor é convencido a buscar alguma coisa em nome do atacante.

A lista é revisada de tempos em tempos e os nomes mudam um pouco de uma edição pra outra. A natureza do que está nela não muda.

Nenhuma delas é engenhosa. É exatamente por isso que continuam funcionando.

O que isso quer dizer pra você

Você não precisa decorar nada. A lista importa pra quem constrói descrevendo o que quer porque ela dá forma a uma preocupação vaga. "Meu app está seguro" não tem resposta. "Uma pessoa deslogada consegue abrir este endereço" tem, e você mesmo testa em trinta segundos.

É isso que uma análise faz quando roda no seu app: percorre uma lista como essa, por fora, fazendo as perguntas específicas no lugar da vaga. O que você faz com as respostas é a outra metade do problema, e é por causa dessa metade que quase nenhum relatório de segurança vira conserto.