Por que indie hackers, solopreneurs e vibe coders precisam de pentest

Velocidade não é o problema. O que você não vê é.

Você tirou um produto do papel em algumas semanas: IA gerando o código, Supabase ou Firebase no backend, Stripe no checkout, deploy na Vercel. Funciona, tem os primeiros usuários, talvez os primeiros pagantes. Parabéns — e é exatamente aqui que o risco aparece.

O problema não é a velocidade. É que as falhas que derrubam um SaaS pequeno são as mais banais — autenticação, autorização, lógica de pagamento — e são justamente as que um modelo de IA reproduz com confiança, porque aprendeu com milhões de exemplos igualmente inseguros. "Compila e roda" não é "está seguro".

Por que vibe coding herda vulnerabilidades clássicas

Quando você pede à IA um endpoint que "retorna os dados do usuário", ela entrega algo que funciona no happy path. O que ela quase nunca adiciona sem você pedir explicitamente:

• verificação de que o usuário logado é dono do recurso que está pedindo;
• validação de que o preço veio do servidor, não do frontend;
• limite de tentativas no login e no reset de senha;
• checagem de que o webhook do Stripe é autêntico antes de liberar acesso.

Nada disso aparece na demo. Tudo isso aparece quando alguém — curioso ou mal-intencionado — troca um número na URL.

As cinco falhas que mais derrubam produto solo

1. IDOR: o id na URL

GET /api/projects/123 devolve o seu projeto. /api/projects/122 devolve o do vizinho, porque o backend confia no ID sem checar dono. É o vazamento de dados mais comum em SaaS pequeno, e enumerável em minutos.

2. Preço definido no cliente

O checkout manda { "plan": "pro", "price": 4900 }. Se o backend confia no price recebido em vez de buscar no seu catálogo, o cliente paga o que quiser — inclusive R$ 1. Pagamento é lógica de servidor, sempre.

3. Webhook do Stripe sem verificação de assinatura

O endpoint que libera o plano pago é chamado por um POST. Se você não valida a assinatura do webhook, qualquer um manda esse POST e vira assinante premium de graça.

4. Reset de senha e login sem limite

Sem rate limit, o login vira alvo de força bruta e o "esqueci a senha" vira ferramenta de enumeração de e-mails cadastrados. Barato de explorar, caro de descobrir depois.

5. Segredos no lugar errado

Chave da OpenAI, service_role do Supabase, token do Stripe — no bundle do frontend, num .env commitado, ou expostos por uma rota de debug. Um service_role vazado é acesso total ao banco, ignorando qualquer regra de RLS.

E se o seu produto usa IA?

Se você colocou um chatbot, um agente ou um "pergunte à IA" no produto, herdou uma superfície nova: prompt injection, vazamento do system prompt, abuso das ferramentas que o modelo pode chamar. Um usuário pode convencer o seu assistente a fazer o que você não autorizou. É escopo próprio, e vale testar antes de conectar o modelo a dados ou ações de verdade.

Você não precisa de um pentest enterprise

O instinto do indie hacker é adiar segurança "até ter escala". Mas o custo de um incidente — vazamento de dados de clientes, fraude no pagamento, conta comprometida — chega antes da escala, e para um produto solo pode ser fatal em reputação. Ao mesmo tempo, você não precisa do pacote de auditoria de banco.

O que faz sentido nesse estágio é um teste enxuto e focado: autenticação, autorização, lógica de pagamento, exposição de segredos e, se houver, a camada de IA. Poucos dias, um relatório direto com o que corrigir por ordem de risco, e reteste depois que você ajustar. É o suficiente para não ser derrubado pelo básico.

Como a Pentest Machine testa isso

Atendemos desde produto solo até enterprise, com escopo proporcional ao seu estágio: um pentest focado nas falhas que realmente afetam SaaS pequeno, com PoC reproduzível, prioridade por risco e reteste incluso — e cobertura de IA/LLM quando o seu produto tem assistente. Se você lançou rápido e agora tem usuários reais, é o momento de descobrir o que a IA não te avisou antes que um estranho descubra.