Checklist

As 8 falhas que a IA mais deixa no seu projeto.

Uma por uma: por que importa, como conferir à mão e o que fazer. Leva uns 30 minutos no seu projeto — ou um comando, se preferir que o VibeDefender confira as oito de uma vez:

  1. 01

    Chave secreta no navegador ou no código

    Tudo o que vai para o navegador — ou para dentro de um app que as pessoas instalam — pode ser lido por qualquer um. E a chave escrita no código vai junto para o GitHub, onde robôs procuram chaves o dia inteiro.

    Como conferir

    • Procure variáveis com prefixo público (NEXT_PUBLIC_, VITE_, EXPO_PUBLIC_) guardando chave secreta.
    • A chave service_role do Supabase nunca pode aparecer no código do front.
    • No site no ar, abra as ferramentas do navegador e busque por "sk_", "service_role" ou "secret" nos arquivos carregados.
    • No código que vai para o GitHub (Python, PHP, bot, script), procure chaves escritas direto no arquivo em vez de lidas de uma variável de ambiente.

    Se achar: Mova a chamada que usa a chave para o servidor e troque a chave que já ficou exposta.

  2. 02

    Arquivo .env enviado para o GitHub

    O .env guarda as suas senhas. Se ele foi versionado, qualquer pessoa com acesso ao repositório — ou ao histórico dele — tem as chaves.

    Como conferir

    • Rode git ls-files | grep .env na pasta do projeto: não pode aparecer nada além de .env.example.
    • Confira se o .gitignore tem uma linha com .env.

    Se achar: Tire o arquivo do Git, coloque no .gitignore e troque todas as chaves que estavam nele — apagar o arquivo não apaga o histórico.

  3. 03

    Tabela do banco aberta para qualquer um

    No Supabase, uma tabela sem RLS (ou com uma regra que libera tudo) pode ser lida e alterada por qualquer visitante, com a chave pública do seu próprio site.

    Como conferir

    • No painel do Supabase, cada tabela precisa estar com RLS ligado.
    • Desconfie de política com using (true): ela libera todo mundo.
    • As políticas de tabelas com dado de usuário devem filtrar pelo dono, com auth.uid().

    Se achar: Ligue o RLS e escreva uma política por operação que confira quem é o dono de cada linha.

  4. 04

    Qualquer site pode chamar sua API

    CORS aberto para qualquer origem, junto com o login do usuário, deixa outro site agir em nome de quem está logado no seu.

    Como conferir

    • Procure Access-Control-Allow-Origin com * ou que repete a origem de quem pediu.
    • Se aparecer junto de Allow-Credentials: true, é o caso perigoso.

    Se achar: Libere só o endereço do seu próprio site, numa lista fixa.

  5. 05

    Dados de outro usuário trocando o ID

    A rota funciona, o login funciona — e trocar um número na URL entrega o pedido ou o documento de outra pessoa.

    Como conferir

    • Em cada rota que recebe um id, veja se a busca também filtra pelo usuário logado.
    • Teste de verdade: com duas contas, abra um item da primeira logado na segunda.

    Se achar: Sempre busque pelo id E pelo dono vindo da sessão — nunca só pelo id que veio da requisição.

  6. 06

    Cookie de login desprotegido

    Um cookie de sessão sem as proteções certas pode ser lido por um script injetado ou enviado por outro site.

    Como conferir

    • Os cookies de sessão precisam de HttpOnly, Secure e SameSite (Lax ou Strict).

    Se achar: Ligue as três opções na hora de criar o cookie.

  7. 07

    Consulta ao banco montada com texto

    Juntar o que vem da requisição dentro de um SQL é a porta clássica para injeção: quem manda o texto escolhe a consulta.

    Como conferir

    • Procure consultas montadas com template string ou concatenação usando dados da requisição.

    Se achar: Use consultas com parâmetros, ou os métodos do seu cliente de banco que já fazem isso.

  8. 08

    Rota de API sem verificação de login

    É o mais comum em projeto feito com IA: a rota grava no banco, gasta a sua conta paga ou mexe no servidor sem conferir quem está chamando.

    Como conferir

    • Abra cada rota que grava, apaga ou chama serviço pago: a primeira coisa dela deve ser conferir a sessão.
    • Webhook é diferente: ele não tem sessão, e precisa conferir a assinatura do remetente.

    Se achar: Confira a sessão no servidor, responda 401 sem ela e use o id do usuário que veio da sessão.

Confira as oito de uma vez.

O plano gratuito roda as oito verificações e mostra quantos problemas cada uma encontrou. O Pro mostra em qual arquivo e linha está cada um, e entrega o prompt pronto para colar na sua IA.

Ver os planos