guia · owasp · llm security
O OWASP Top 10 for LLM Applications é a lista de referência dos riscos de segurança de aplicações que usam modelos de linguagem. Este guia traduz cada item em algo concreto para quem construiu o produto com Cursor, Lovable, Bolt, v0 ou Claude Code — onde o app já está no ar e a superfície de ataque veio junto com o código gerado.
LLM01
Texto do usuário (ou de um documento, e-mail, página raspada) é concatenado ao prompt e passa a valer como instrução. O atacante sobrescreve o system prompt, vaza contexto ou aciona ferramentas que não deveria.
Separe instrução de dado: input do usuário sempre em mensagem própria, delimitado e rotulado como não confiável. Nunca dê à LLM uma ferramenta cujo abuso você não aceitaria.
LLM02
A resposta do modelo é tratada como confiável: renderizada como HTML, executada como SQL, passada a eval ou usada para montar uma rota. É XSS e RCE com passo intermediário.
Trate a saída da LLM como input de usuário: escape na renderização, valide contra um schema (Zod) antes de qualquer uso estrutural, nunca execute o texto gerado.
LLM03
Dependências, modelos e plugins de terceiros entram no app sem revisão. Em vibe coding é comum a IA sugerir um pacote pouco mantido — ou inexistente, que um atacante registra depois.
Fixe versões, rode scan de dependências e confira se cada pacote sugerido pela IA realmente existe e é mantido.
LLM04
Rotas de IA sem limite: um único usuário dispara milhares de chamadas com contexto enorme. O impacto não é só indisponibilidade, é fatura.
Rate limiting por usuário e por IP, teto de tokens por requisição e alerta de custo diário.
LLM06
O modelo devolve dados de outro tenant, trechos do system prompt ou chaves que estavam no contexto. A causa raiz costuma ser a mesma de sempre: o dado nunca deveria ter sido buscado.
Filtre no banco, não no prompt. RLS por usuário antes do retrieval, e segredo nenhum dentro do contexto enviado ao modelo.
LLM08
O agente tem permissão de escrita, deleção ou pagamento porque ficou mais fácil assim. Uma injection bem-sucedida herda tudo isso.
Menor privilégio por ferramenta, confirmação humana em ações destrutivas ou financeiras, e log de toda chamada de tool.
Ferramentas automáticas cobrem o que é sintático: dependência vulnerável, segredo commitado, padrão perigoso conhecido. Metade do Top 10 de LLM é lógica de negócio — excesso de permissão de um agente, vazamento entre tenants, uma ferramenta que jamais deveria estar exposta ao modelo. Nenhum scanner sabe qual dado o usuário B pode ver.
A revisão manual é a ponte entre “o CI passou” e “dá para colocar em produção”: alguém lê o fluxo, tenta quebrar o app como um atacante e devolve o diff da correção.
É a lista de referência mantida pela OWASP com os riscos de segurança mais críticos em aplicações que usam modelos de linguagem, do prompt injection ao excesso de autonomia de agentes.
Não existe solução 100% à prova de falhas, mas dá para reduzir drasticamente o risco: separando instrução de dado, tratando toda saída do modelo como não confiável e limitando o que cada ferramenta do agente pode fazer.
Só parcialmente. Eles detectam dependências vulneráveis e segredos commitados, mas metade do Top 10 de LLM é lógica de negócio — excesso de permissão, vazamento entre tenants — que exige revisão manual.
Vale para qualquer aplicação que envie input de usuário para um LLM ou use um agente com acesso a ferramentas — busca, banco de dados, pagamentos, e-mail — não só chatbots.
Envie o repositório e receba um relatório de findings priorizado em 24–48h.
Solicitar revisãoLeia também: Conheça a revisão de segurança · Ver todos os posts · Security code review para apps de IA · Checklist de segurança do Supabase RLS · Claude Code vs Cursor vs Windsurf