Vibecoding
3 perguntas pra saber se seu app está seguro
Você não precisa auditoria completa pra começar. Precisa responder três perguntas com honestidade.
Segurança assusta porque parece um oceano. Firewall, criptografia, pentest, OWASP. Você não sabe por onde começar, então não começa. E o app sobe torcendo pra dar certo.
Meu take: você não precisa auditar tudo pra melhorar muito. Precisa responder três perguntas com honestidade brutal. Elas pegam a maioria dos erros de projeto pequeno.
Pergunta 1: meus segredos estão protegidos?
Segredo é chave de API, senha de banco, token. A pergunta real é: se alguém abrir meu repositório agora, encontra alguma chave?
Cheque:
- Tem chave escrita direto no código? Erro.
- O arquivo .env está no gitignore?
- Já commitei segredo antes, mesmo que depois removi? Se sim, ele ainda está no histórico e precisa ser rotacionado.
Teste rápido. Procure no seu projeto:
grep -r "sk-" .
grep -r "API_KEY" .
Achou chave de verdade no código versionado? Você tem trabalho urgente. Chave vazada em repositório é o erro que bot explora em minutos.
Pergunta 2: meus dados estão fechados por padrão?
A pergunta: se alguém descobrir o endereço do meu banco ou da minha API, ele consegue ler o que não deveria?
O erro clássico está aqui. No Firebase, a regra aberta:
allow read, write: if true;
Isso libera geral. Qualquer pessoa lê e escreve tudo. Já vi app sério no ar com isso, expondo dado de milhares de usuários.
O certo começa fechado e libera o mínimo:
allow read: if request.auth.uid == resource.data.ownerId;
Cheque:
- Minhas rotas de API pedem autenticação onde precisam?
- O usuário A consegue ver os dados do usuário B?
- Meu banco aceita conexão de qualquer lugar?
Se um usuário logado consegue puxar dado de outro trocando um ID na URL, você tem um buraco. Chama-se acesso indireto, e é dos mais comuns.
Pergunta 3: eu confio no que entra?
Todo dado que vem de fora é suspeito. A pergunta: eu valido o que chega antes de usar?
Cheque:
- Formulários validam no servidor, não só no front?
- Input vira query de banco com concatenação? Isso é SQL injection.
- Input vira HTML na tela sem tratamento? Isso é XSS.
- Tem limite de tamanho nos campos?
O exemplo que não pode existir:
db.query("SELECT * FROM users WHERE email = '" + input + "'")
Isso é convite pra invasão. O certo usa parâmetro e nunca cola input direto na query.
O que fazer com as respostas
Simples. Toda pergunta que você respondeu "não" ou "não sei" é seu próximo trabalho. Antes de qualquer feature nova.
Segurança não é tudo ou nada. É melhorar uma camada por vez. Essas três perguntas cobrem os erros que mais aparecem em projeto de vibecoder: segredo vazado, dado aberto e input não validado.
Vibecoding com engenharia é ter a coragem de responder essas três com honestidade, mesmo quando a resposta dói. Melhor você descobrir o buraco do que o atacante.
A decisão é sua.
Perguntas frequentes
Perguntas rápidas
+Isso substitui uma auditoria de seguranca?
Nao. Mas cobre os erros mais comuns de projeto pequeno. E o filtro que pega 80% dos problemas com 20% do esforco.
+Se eu responder nao pra alguma?
Voce achou seu proximo trabalho. Comece por essa antes de adicionar qualquer feature nova.
+Com que frequencia devo revisar?
Antes de todo deploy importante e sempre que adicionar algo que mexe com dado ou acesso.
Continue lendo
Como não virar refém de uma ferramenta de IA
A ferramenta que você ama hoje pode dobrar de preço, mudar de dono ou fechar amanhã. Não construa em cima de uma só.
VibecodingO que fazer quando a IA te dá código que você não entende
A tentação é apertar aceitar e seguir. Não faça. Código que você não entende é código que você não mantém.
VibecodingPor que backup não é opcional
Existe quem faz backup e quem ainda não perdeu tudo. Você escolhe de qual lado ficar antes ou depois.