5 Falhas de Segurança que a IA Deixa no Seu Código

5 Falhas de Segurança que a IA Deixa no Seu Código

Você terminou seu aplicativo com a ajuda do ChatGPT, Claude ou Cursor, testou tudo funcionando lindamente e colocou no ar. Só que existe uma chance grande de que ele esteja com a porta destrancada.

Um levantamento da Symbiotic Security escaneou 1.072 aplicativos criados com IA e achou pelo menos uma falha de segurança em 98% deles. Apenas 26 passaram limpos.

Neste artigo você vai conhecer os 5 erros de segurança mais comuns nesse tipo de projeto e as ferramentas gratuitas para encontrar e corrigir cada um antes que alguém mal-intencionado encontre primeiro.

Programador revisando código em busca de falhas de segurança
Revisar o código gerado por IA é parte essencial do processo de desenvolvimento. Foto: Jakub Zerdzicki / Pexels.

Os 5 erros de segurança mais comuns em código gerado por IA

Segundo uma análise da Veracode, 45% do código gerado por IA tem pelo menos uma falha do OWASP Top 10 — a lista oficial dos riscos de segurança mais graves em aplicações web.

Um estudo com base em pesquisa de Stanford mediu que desenvolvedores que usam IA produzem cerca de 40% mais vulnerabilidades, principalmente porque confiam no código sem revisar.

1. Row Level Security desligado no Supabase ou Firebase. Nessas ferramentas, o banco de dados conversa direto com o navegador do usuário, sem um servidor filtrando o que cada um pode ver. Sem essa trava (RLS), qualquer pessoa com conhecimento básico consegue puxar dados de outros usuários direto pelo inspecionar do navegador.

2. Regra de negócio decidida no frontend. Um erro clássico é deixar toda a validação — inclusive quem é administrador do sistema — sendo decidida só na tela, com um “if” escondendo um botão. Quem sabe abrir o inspecionar do navegador ignora essa regra completamente.

3. Rotas de backend sem checar quem está pedindo. A API devolve o dado sem confirmar se o usuário autenticado realmente tem permissão para ver aquele registro específico — um problema conhecido como IDOR, que está no topo do OWASP API Security Top 10.

4. Chave de API exposta. Quando o frontend é compilado, toda variável de ambiente vira texto JavaScript legível por qualquer pessoa que abrir o inspecionar. Só em 2024, 24 milhões de chaves e senhas vazaram publicamente no GitHub — e bots varrem repositórios novos em busca disso 24 horas por dia.

5. Confiar em qualquer coisa que o usuário digita. Campos sem validação abrem espaço para XSS (injeção de código malicioso) e upload de arquivos sem checar o tipo — dois vetores de ataque simples de evitar e comuns de esquecer.

💡 Dica Iazando: Se você usa Supabase ou Firebase, ative o RLS em toda tabela assim que criar ela — antes de escrever a primeira linha de frontend. O comando é simples: ALTER TABLE nome_da_tabela ENABLE ROW LEVEL SECURITY;. Deixar essa configuração pra depois é a forma mais comum de esquecer dela de vez.

4 ferramentas gratuitas para escanear seu projeto

A boa notícia é que existem ferramentas de código aberto — sem dono comercial e gratuitas — que fazem boa parte dessa auditoria por você.

Ferramenta O que faz Ideal para
OWASP ZAP Escaneia a aplicação no ar em busca de portas e falhas abertas Qualquer app publicado
Gitleaks Encontra chaves e senhas expostas no código e no histórico do Git Todo projeto antes do deploy
Bandit Analisa código Python em busca de padrões inseguros Projetos em Python
Opengrep Análise estática que procura SQL Injection, XSS e segredos no código Times que querem automatizar a checagem

Todas são mantidas por fundações ou comunidades abertas, sem custo de licença. O OWASP ZAP, em especial, já pode ser integrado direto ao fluxo de agentes de IA como o Claude Code.

Se preferir uma checagem rápida sem instalar nada agora, existe um caminho mais simples: pedir para o próprio assistente de IA revisar o código com esse foco específico, listando cada falha encontrada, o arquivo, a linha e como corrigir.

Checklist de segurança antes de colocar no ar

1

RLS ativo em toda tabela
Com políticas específicas por usuário, não apenas ligado no geral.

2

Chave de administrador fora do frontend
Só a chave pública (anon) pode aparecer no navegador.

3

Toda decisão de permissão conferida no servidor
Nunca só na tela — o navegador pode ser manipulado.

4

Endpoints que recebem um ID validam o dono
Antes de devolver qualquer dado da consulta.

5

Nenhuma chave de API no código do front ou no Git
Coloque o arquivo .env no .gitignore desde o primeiro commit.

6

Todo input validado e todo upload checado
Isso fecha as portas de XSS e envio de arquivo malicioso.

Como pedir uma revisão de segurança ao próprio assistente de IA

Um bom começo é pedir de forma específica. Em vez de “revise meu código”, experimente algo como: “Revise este projeto com foco em segurança. Liste cada falha encontrada, o arquivo, a linha e como corrigir. Verifique principalmente permissões de banco de dados, chaves expostas e validação de dados de entrada.”

Depois, não aceite tudo sem pensar: peça a explicação de cada ponto e confira se a correção sugerida faz sentido para o seu caso.

Servidor de banco de dados com um cadeado representando proteção de dados
Regras de acesso ao banco de dados devem ser configuradas antes de publicar o aplicativo. Foto: panumas nikhomkhai / Pexels.

Quando vale chamar um profissional

  • O aplicativo guarda dados pessoais, financeiros ou de saúde de outras pessoas.
  • Há pagamentos, login de usuários ou informações sensíveis envolvidas.
  • Você não tem certeza se as regras de acesso estão configuradas corretamente.
  • O projeto vai crescer e atender muitos usuários.

Ferramentas gratuitas ajudam muito, mas uma revisão de quem entende de segurança reduz o risco quando o projeto passa de um experimento para algo que outras pessoas usam de verdade.

Perguntas frequentes

O que é o OWASP Top 10?

É a lista oficial dos riscos de segurança mais graves em aplicações web, citada no artigo como referência para medir falhas em código gerado por IA.

O que é o Row Level Security?

É uma trava que controla quais linhas de uma tabela cada usuário pode ver. Sem ele, em serviços como Supabase ou Firebase, qualquer pessoa com conhecimento básico pode acessar dados de outros usuários.

As ferramentas gratuitas do artigo substituem uma auditoria profissional?

Não. Elas encontram muitas falhas comuns, mas não substituem a revisão de quem entende de segurança em projetos que lidam com dados sensíveis.

Conclusão

A inteligência artificial não deixa essas portas abertas de propósito — ela faz exatamente o que foi pedida, e ninguém costuma pedir “e deixa isso seguro”. Segurança é a parte que precisa entrar no seu prompt e na sua revisão manual, porque ela não aparece na tela como um resultado visual bonito.

Antes de colocar seu próximo projeto no ar, rode pelo menos um scanner gratuito da lista acima — leva poucos minutos e evita uma dor de cabeça bem maior depois. Continue no blog do Iazando para mais guias práticos de IA aplicada ao dia a dia.