Aula 4 · 25 min
Fazer app com IA ficou fácil: o gerente descreve, a ferramenta entrega um site com banco de dados em uma tarde. O que a IA não faz sozinha é fechar as portas. Nesta aula você revisa um app desses só lendo: segredo exposto, falta de login, banco aberto e peça velha. Você diagnostica; quem corrige é o time.
Começar a aula
Objetivo: achar segredo exposto, rota sem login, banco sem RLS e dependência vulnerável num app feito por IA, só lendo o projeto.
Vibe coding é construir app descrevendo em linguagem comum para a IA. Revise nesta ordem. Clique em cada camada.
Você só lê o projeto (cópia ou repositório liberado no termo). Não testa ataque no site no ar.
O método completo tem 7 etapas. As 3 primeiras são suas; as outras são do time que corrige, e você confere no fim.
Leia o projeto nas 4 camadas. Nada é alterado. O que não deu para ver vira "não verificado".
Segredo encontrado: anote arquivo, linha e os 4 primeiros caracteres. Nunca copie a chave inteira.
app.js, CONFIG.openaiApiKey: chave de IA no navegador (começa com FAKE…).
Para cada achado: camada, arquivo e linha, prova, gravidade (régua da aula 3) e "não verificado" quando for o caso.
Escreva para o dono entender: o que acontece se ninguém fizer nada.
Qualquer pessoa que abrir o app pode copiar a chave e usar a IA na conta da Horizonte.
Para cada achado, a correção sugerida e o risco dela: segura, moderada ou arriscada (pode quebrar o app?).
Crítico com correção segura vai primeiro. Correção arriscada só com ok do dono e teste antes.
Trocar a chave: crítico, correção moderada (o app para de sugerir produtos até a nova chave ir para o servidor).
Quem corrige é o time ou o fornecedor: faz backup, testa numa cópia, aplica um item por vez.
No fim, você repete o diagnóstico e entrega a tabela "antes × depois". Sem essa conferência, a correção não está provada.
F2 · antes: RLS desligada · depois: RLS ligada, testada com dois usuários · status: resolvido.
O checklist guia você. O pedido serve para um agente de IA (Claude Code, Codex) ler o projeto sem mudar nada.
CHECKLIST DE VIBE AUDIT · <app> · <data> · avaliador: <nome> Marque: [ok] [achado] [não verificado] — sempre com evidência SEGREDOS [ ] Nenhuma chave/senha/token em arquivo que vai para o navegador (.js, .html) [ ] .env NÃO está no repositório (nem no histórico) [ ] .gitignore lista .env e arquivos de chave [ ] Variáveis públicas (ex.: NEXT_PUBLIC_, VITE_) não guardam segredo [ ] Chave "service_role" ou de administrador nunca no front [ ] Existe limite de gasto no provedor da IA LOGIN E ACESSO [ ] Páginas de admin exigem login [ ] O login é conferido no servidor, não só escondendo o botão [ ] Rotas de API conferem a sessão e o papel (admin x cliente) [ ] Admin tem verificação em 2 etapas BANCO DE DADOS [ ] RLS ligada em TODAS as tabelas com dado de cliente ou pedido [ ] Existe política "cada um vê só o seu" [ ] Usuário anônimo (anon) não tem permissão de ler/alterar tudo [ ] Testado com 2 usuários diferentes (um não vê o do outro) DEPENDÊNCIAS [ ] Lista de dependências conferida (npm audit ou equivalente) [ ] Nenhuma versão com falha conhecida (CVE) de gravidade alta [ ] O framework ainda recebe correções [ ] Alguém é dono das atualizações PUBLICAÇÃO [ ] O app está público de propósito (a plataforma não deixou aberto por padrão) [ ] Dados de teste não são dados reais de clientes NÃO VERIFICADO (com motivo): <...>
Você vai revisar a segurança deste projeto SÓ LENDO. Regras: - Não altere, crie nem apague nenhum arquivo. - Não rode comando que acesse a internet, instale pacote ou suba servidor. - Nunca mostre um segredo inteiro: só arquivo, linha e os 4 primeiros caracteres. - O que você não conseguir confirmar, marque como "não verificado". Revise 4 camadas e entregue uma tabela (camada | arquivo:linha | o que achou | por que é risco | gravidade crítica/alta/média/baixa): 1. Segredos: chaves, senhas, tokens em arquivos enviados ao navegador ou ao repositório. 2. Login: páginas e rotas de admin ou internas sem conferência de login no servidor. 3. Banco: tabelas sem RLS, permissões amplas para usuário anônimo. 4. Dependências: versões com vulnerabilidade conhecida (cite o CVE se souber; se não tiver certeza, diga). No fim, liste o que ficou "não verificado" e por quê.
Na empresa-laboratório. Falhas desta aula: F1, F2, F3 e F4, todas no app de pedidos.
Abra o app de pedidos do laboratório e os arquivos dele (app.js, supabase-config.json, schema.sql, admin.html, package.json). Passe o checklist inteiro.
Pronto quando: você achou as 4 falhas plantadas (F1 a F4), cada uma com arquivo, prova, gravidade pela régua da aula 3 e correção sugerida com o risco da correção.
Para cada uma das 4 falhas, escreva uma frase para o Carlos (dono, não técnico) dizendo o que acontece se ninguém fizer nada.
Pronto quando: as 4 frases têm no máximo 25 palavras cada e nenhuma usa sigla sem explicar.
A explicação aparece depois da sua resposta.
Pergunta 1 de 4
O app usa Supabase e a chave "anon" está no código do navegador. Isso, sozinho, é o achado?competência
Pergunta 2 de 4
O painel admin abre sem login, mas "ninguém sabe o endereço". Como classificar?competência
Pergunta 3 de 4
Você achou uma dependência com falha conhecida. Você atualiza a versão?
Pergunta 4 de 4
Para que serve pedir a um agente de IA que leia o projeto?
Escolha uma alternativa. A explicação aparece depois da sua tentativa.