[Vibe Coder #8] 6 verificações de segurança antes de aceitar usuários

O app está pronto, implantado, e agora só falta publicar o link para o mundo. O último artigo da série é a checagem final antes disso: seis verificações de segurança antes de aceitar usuários e o resumo completo do mapa construído desde a Parte 1.

Antes, vamos esclarecer um equívoco comum: “Meu app é pequeno e nem é famoso; quem o atacaria?”. Como vimos na Parte 2, os atacantes não são pessoas, mas bots. Bots não escolhem alvos; eles lançam uma rede. Eles varrem automaticamente todos os endereços públicos da internet em busca de portas abertas. Um app pequeno não é seguro; simplesmente ninguém está cuidando dele. Felizmente, as portas exploradas em apps de vibe coding geralmente são previsíveis, e estas seis são as principais.

6 verificações antes de publicar

1. Algum segredo está vazando? Esta é a verificação da Parte 2. Confirme que as chaves de API não estão expostas no frontend nem em um repositório público do GitHub. Peça à IA: “Encontre todos os casos neste projeto em que uma chave de API ou um segredo foi enviado ao frontend ou commitado no Git.”

2. As verificações de autorização estão no backend? Este é o princípio da Parte 1. Esconder o botão de exclusão é apenas decoração; qualquer pessoa pode enviar a solicitação. Para excluir, editar e consultar posts, o backend precisa verificar: “Este usuário tem permissão para fazer isso?”. Peça à IA: “Audite todas as APIs do backend para confirmar que verificam login e propriedade, e liste o que estiver faltando.”

3. Qualquer pessoa pode entrar no DB? O armazém (DB) tem suas próprias regras de acesso. No Supabase, isso é RLS (Row Level Security, segurança em nível de linha): em termos simples, regras na porta do armazém que definem quem pode ler e escrever cada linha. Se estiver desativado, abre-se um caminho para invadir o armazém diretamente, sem passar pelo backend. Em incidentes reais com apps de vibe coding, este é o item mais apontado. Peça à IA: “Verifique se alguma tabela do meu DB pode ser lida ou escrita por qualquer pessoa e me diga como bloqueá-la.”

4. O app está preparado para entradas estranhas? Usuários inserem qualquer coisa: um post de 100 mil caracteres, trechos de código estranhos ou valores vazios. Se o backend não validar o tamanho e o formato da entrada, o app pode quebrar ou ser invadido. Peça à IA: “Verifique se todos os locais que recebem entradas do usuário têm limite de tamanho e validação de formato.”

5. Existe uma proteção contra cobranças excessivas? Esta é a configuração de cinco minutos da Parte 7: limite de gastos e alertas de orçamento. A partir do momento em que surgem usuários, o volume de chamadas deixa de estar sob meu controle; portanto, publicar é a última chance de configurar isso.

6. Existe um caminho de volta? Este é o ponto de salvamento da Parte 3. Faça commit e push do estado imediatamente anterior à publicação e confirme que os backups do DB estão ativados. Quando ocorrer o primeiro incidente após a publicação, poder voltar ao “momento em que funcionava” determinará a velocidade da recuperação.

Se conferir as seis parecer trabalhoso, execute pelo menos este último recurso: “Você é um auditor de segurança. Antes de publicar este projeto, encontre todos os pontos perigosos sob as perspectivas de exposição de segredos, falhas nas verificações de autorização, regras de acesso ao DB e validação de entrada, e informe-os em ordem de gravidade.” Até uma IA que cometeu erros durante a criação consegue encontrá-los quando solicitada a auditar. Mas não confie cegamente no “Agora está seguro” da IA; comparar com esta lista e verificar cada item também faz parte da checagem.

Resumo da série: um mapa em uma página

Quando dobramos as oito partes em uma página, fica assim.

• Parte 1 — Estrutura: um app é um salão (frontend), uma cozinha (backend) e um armazém (DB). O frontend é um espaço público, portanto não coloque segredos nele.
• Parte 2 — Chaves de API: uma chave é um cartão corporativo. Ela pertence a apenas dois lugares: .env e o painel de implantação.
• Parte 3 — Git: um commit é um salvamento. Salve sempre que tudo funcionar e antes de cada grande alteração.
• Parte 4 — Implantação: implantação é uma mudança para um servidor. .env não vai junto com a mudança, então cadastre-o separadamente no painel.
• Parte 5 — Erros: uma mensagem de erro é uma confissão. Entregue-a inteira à IA, junto com o contexto. Se a IA ficar dando voltas, mude a abordagem.
• Parte 6 — Mistérios: os culpados por “não mudei nada” são cache, dependências, serviços externos e o seu eu de ontem. Comece pelas verificações mais baratas.
• Parte 7 — Custos: a cobrança vem de tokens, leituras e gravações e tráfego. Limites de gastos e alertas são um seguro de cinco minutos.
• Parte 8 — Verificações antes da publicação: tranque as seis portas acima antes de sair.

Conclusão

Esta série não ensinou programação. Em vez disso, desenhou um mapa: de quais peças meu app é composto, onde cada peça pode causar problemas e onde olhar e o que dizer à IA quando algo acontecer. A verdadeira habilidade no vibe coding não é saber ler código, mas carregar este mapa e fazer perguntas precisas à IA.

O mapa agora está nas suas mãos. Crie algo bom e mostre ao mundo.

Continue lendo

• Como impedir incidentes de vibe coding desde o início usando arquivos de regras