Porque é que indie hackers, solopreneurs e vibe coders precisam de pentest

A velocidade não é o problema. O que não vê é que é.

Tirou um produto da ideia para produção em poucas semanas: IA a escrever o código, Supabase ou Firebase no backend, Stripe no checkout, deploy na Vercel. Funciona, tem os primeiros utilizadores, talvez os primeiros pagantes. Parabéns — e é exatamente aqui que o risco aparece.

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

Porque é que o vibe coding herda vulnerabilidades clássicas

Quando pede à IA um endpoint que "devolve os dados do utilizador", ela entrega algo que funciona no happy path. O que quase nunca acrescenta sem que peça explicitamente:

• verificar que o utilizador autenticado é dono do recurso que está a pedir;
• validar que o preço veio do servidor, não do frontend;
• limitar as tentativas de login e de reposição de palavra-passe;
• verificar que o webhook do Stripe é autêntico antes de dar acesso.

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

As cinco falhas que mais deitam abaixo um produto a solo

1. IDOR: o id no URL

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

2. Preço definido no cliente

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

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

O endpoint que ativa o plano pago é chamado por um POST. Se não valida a assinatura do webhook, qualquer um envia esse POST e torna-se subscritor premium de graça.

4. Login e reposição de palavra-passe sem limites

Sem rate limit, o login torna-se alvo de força bruta e o "esqueci-me da palavra-passe" torna-se uma ferramenta para enumerar e-mails registados. Barato de explorar, caro de descobrir depois.

5. Segredos no sítio errado

A sua chave da OpenAI, o service_role do Supabase, o token do Stripe — no bundle do frontend, num .env commitado, ou expostos por uma rota de debug. Um service_role revelado é acesso total à base de dados, ignorando qualquer regra de RLS.

E se o seu produto usa IA?

Se acrescentou um chatbot, um agente ou um "pergunte à IA", herdou uma superfície nova: prompt injection, fuga do system prompt, abuso das ferramentas que o modelo pode chamar. Um utilizador pode convencer o seu assistente a fazer o que não autorizou. É um âmbito próprio, e vale a pena testar antes de ligar o modelo a dados ou ações reais.

Não precisa de um pentest enterprise

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

O que faz sentido nesta fase é um teste focado e leve: autenticação, autorização, lógica de pagamento, exposição de segredos e, se existir, a camada de IA. Poucos dias, um relatório direto com o que corrigir por ordem de risco, e um reteste depois de corrigir. Suficiente para não cair pelo básico.

Como a Pentest Machine testa isto

Trabalhamos desde o produto a solo até ao enterprise, com âmbito proporcional à sua fase: um pentest focado nas falhas que realmente afetam um SaaS pequeno, com PoC reproduzível, prioridade por risco e reteste incluído — mais cobertura de IA/LLM quando o seu produto tem assistente. Se lançou depressa e agora tem utilizadores reais, é o momento de descobrir o que a IA não o avisou antes que um estranho o descubra.