Módulo 1.7 — Controle, Qualidade e Segurança Básica

⚠️ O dado que assusta

Vibe coding acelera o desenvolvimento — e também acelera a introdução de vulnerabilidades. O relatório CodeRabbit 2025 analisou mais de 1 milhão de pull requests e chegou a um número que todo vibe coder precisa conhecer: código assistido por IA tem 2,74x mais vulnerabilidades do que código escrito por humanos sem assistência.

📊 Os números reais (CodeRabbit 2025)

2,74x mais vulnerabilidades em código gerado com assistência de IA
45% do código gerado por IA contém pelo menos uma falha de segurança (Veracode)
16 de 18 CTOs consultados sobre vibe coding em produção reportaram incidentes
Top vulnerabilidades: SQL injection, XSS, dados hardcodados, IDOR (acesso a recursos de outros usuários)

💡 O contexto importa

Esses números não significam que vibe coding é perigoso por natureza — significam que sem processo de revisão, qualquer metodologia de desenvolvimento é perigosa. Os riscos são gerenciáveis com as práticas que você aprende neste módulo.

A maioria dos incidentes aconteceu em projetos onde o desenvolvedor aceitou código sem revisar, não usou variáveis de ambiente e colocou diretamente em produção sem teste.

🔒 Git como rede de segurança

Git não é só controle de versão — é sua apólice de seguro para vibe coding. Commits frequentes criam um histórico de estados funcionais que você pode acessar a qualquer momento. O momento em que você vai precisar de rollback é o pior momento para perceber que não fez commits.

🔄 Os comandos de segurança mais importantes

# Ver o que mudou antes de commitar
git diff

# Voltar um arquivo para o estado do último commit
git checkout HEAD -- arquivo.tsx

# Voltar o projeto inteiro para um commit específico (temporariamente)
git checkout abc1234

# Criar uma branch de segurança antes de mudança grande
git checkout -b backup/antes-da-refatoracao

# Ver histórico de commits com diffs
git log --oneline

📊 Frequência de commits recomendada

A cada funcionalidade funcionando — não espere uma PR perfeita
Antes de cada mudança grande — refatorações, novos frameworks, mudanças de arquitetura
Antes do final do dia — mesmo que seja trabalho em progresso (use WIP: no título)
Sempre antes de testar algo experimental — se a IA vai propor uma abordagem nova, commite antes

🔑 Variáveis de ambiente — segredos fora do código

A vulnerabilidade número 1 em projetos vibe coding: chaves de API, tokens e senhas hardcodadas no código. A IA frequentemente coloca valores diretamente no código para "facilitar o exemplo". Se você commitar isso em um repositório — especialmente público — as consequências podem ser imediatas e sérias.

⚠️ O cenário de vazamento mais comum

// Código gerado pela IA — NUNCA faça isso

const stripe = require('stripe')('sk_live_ABC123REAL_KEY')

const db = postgres('postgresql://user:senha@host/db')

Bots escaneiam repositórios GitHub em busca de padrões de chaves da AWS, Stripe, OpenAI, etc. O tempo médio entre o commit de uma chave real e seu primeiro uso malicioso é de 4 a 24 horas.

✅ A forma correta — variáveis de ambiente

Arquivo .env (local, NUNCA commitado)

STRIPE_SECRET_KEY=sk_live_ABC123
DATABASE_URL=postgresql://user:senha@host/db
OPENAI_API_KEY=sk-proj-xyz123

Arquivo .gitignore (sempre inclua .env)

.env
.env.local
.env.production

No código (Next.js / Node.js)

const stripe = require('stripe')(process.env.STRIPE_SECRET_KEY)

💡 Instrução padrão para o agente

Adicione no seu .cursorrules ou CLAUDE.md: "Nunca coloque valores de chaves de API, tokens ou senhas diretamente no código. Sempre use process.env.NOME_DA_VARIAVEL e adicione a instrução no .env.example."

👁️ Revisar o diff antes de commitar

Ler antes de aceitar é o hábito de segurança mais importante do vibe coder. O agente pode ter feito mudanças além do que você pediu, introduzido padrões diferentes dos do projeto ou modificado arquivos que não deveriam ser tocados. O diff é sua última linha de defesa antes do commit.

🔍 O que procurar ao revisar o diff

Arquivos não esperados foram modificados?

Se você pediu para alterar um componente e o diff mostra mudanças em um arquivo de configuração, investigue.

Existem strings suspeitas? (tokens, URLs, senhas)

Procure por padrões como "sk_", "AIza", "Bearer", "postgresql://". Se aparecerem em arquivos de código, alerta vermelho.

Linhas foram deletadas sem motivo claro?

Linhas em vermelho no diff representam código removido. Verifique se a remoção era intencional.

Dependências novas foram adicionadas?

Mudanças em package.json podem incluir dependências com vulnerabilidades conhecidas. Verifique cada pacote novo.

No Cursor / Windsurf

Use o painel de diff integrado para revisar cada mudança antes de aceitar. O botão "Accept All" deve ser o último recurso — prefira "Accept individual changes" para ter controle granular.

No terminal

git diff — mostra mudanças não staged
git diff --staged — mostra o que vai no commit
git diff HEAD~1 — compara com o commit anterior

🛡️ Validação de dados — o mínimo necessário

Uma das vulnerabilidades mais comuns em código de IA: ausência de validação de dados de entrada. A IA foca em fazer o fluxo "feliz" funcionar e frequentemente ignora o que acontece quando o usuário envia dados inesperados, maliciosos ou simplesmente incorretos.

⚠️ Vulnerabilidades por ausência de validação

SQL Injection

Usuário envia '; DROP TABLE users; -- como nome. Sem validação e sanitização, o banco pode ser destruído.

XSS (Cross-Site Scripting)

Usuário envia <script>roubarCookies()</script> em um campo de texto. Se exibido sem sanitização, executa no browser dos outros usuários.

IDOR (Insecure Direct Object Reference)

API retorna qualquer usuário por ID: /api/users/123. Sem verificar se o usuário logado tem acesso ao ID 123, qualquer um pode ver dados de qualquer um.

✅ Validação mínima para cada projeto

✓ Use Zod ou Yup para validar schemas no servidor — não confie em validação apenas no front-end
✓ Use ORMs (Prisma, Drizzle) ao invés de queries SQL manuais — eles previnem injection por padrão
✓ Sanitize HTML se você renderiza conteúdo de usuários — use DOMPurify no front-end
✓ Verifique autorização em cada endpoint — "o usuário logado tem acesso a esse recurso?" deve ser pergunta em toda API

🚫 O que NÃO fazer em produção

Produção é diferente de desenvolvimento. Em dev, um bug é um aprendizado. Em produção, um bug pode significar dados perdidos, usuários prejudicados e, em casos extremos, responsabilidade legal. Este checklist representa os bloqueadores críticos — coisas que devem estar resolvidas ANTES de qualquer deploy.

🚨 Checklist de bloqueadores críticos

Sem chaves hardcodadas — todo segredo em variável de ambiente

Backup do banco antes do primeiro deploy — e antes de qualquer migração

Autenticação testada com usuários reais — fluxos de login/logout/reset de senha

Sem console.log() de dados sensíveis — remove antes de produção

HTTPS obrigatório — certifique-se que o deploy usa SSL

Rate limiting nas APIs — previne abuse e custos inesperados com LLMs

Validação de dados no servidor — nunca confie apenas no front-end

💡 Peça ao agente para auditar

Antes de qualquer deploy de produção: "Faça uma auditoria de segurança básica desse projeto. Liste: chaves hardcodadas, endpoints sem autenticação, inputs sem validação, e console.logs que deveriam ser removidos." É uma revisão extra valiosa que leva menos de 2 minutos.

🆘 Quando chamar um profissional

Vibe coding democratizou o desenvolvimento, mas não eliminou a necessidade de expertise especializada em contextos críticos. Saber quando pedir ajuda profissional é uma habilidade de maturidade — não uma admissão de fraqueza.

📋 Sinais de que você precisa de revisão técnica externa

Dados de usuários reais (PII)

CPF, dados médicos, informações financeiras. LGPD e regulamentações similares têm requisitos específicos que vão além do básico.

Processamento de pagamentos real

Mesmo usando Stripe ou similar, a implementação do checkout, webhooks e conciliação financeira merece olhar especializado.

Mais de 1.000 usuários ativos

Problemas de escalabilidade e performance que o código vibe coded geralmente não trata ficam evidentes nessa escala.

Você não consegue explicar como funciona uma parte crítica

Se há código em produção que você não entende e que lida com dados ou transações — é hora de revisão.

💡 Como contratar revisão técnica

Você não precisa de um dev em tempo integral para uma revisão. Opções acessíveis:

• Code review pontual — plataformas como Codementor para 1-2 horas de revisão focada
• Freelancer sênior — uma semana de revisão e refatoração dos pontos críticos
• Serviços de pentest — para projetos com dados sensíveis, um pentest básico é investimento

✅ Resumo do Módulo 1.7

✓

2,74x mais vulnerabilidades em código de IA — risco real que requer processo de revisão, não abandono da ferramenta

✓

Git é sua rede de segurança — commits frequentes = seguro de rollback sempre disponível

✓

Jamais hardcode segredos no código — variáveis de ambiente para tudo que é sensível

✓

Leia o diff antes de commitar — última linha de defesa contra mudanças não intencionais

✓

Valide dados no servidor — SQL injection, XSS e IDOR são preveníveis com práticas básicas

✓

Saiba quando pedir ajuda — PII, pagamentos reais e mais de 1.000 usuários exigem revisão especializada

Próximo Módulo:

1.8 — 🌐 Deploy: Publicando seu Projeto — Vercel, Render, Railway, domínios e monitoramento básico

← Módulo Anterior Próximo Módulo →