Pular para o conteúdo
Checklist gratuito

O que conferir antes de publicar seu app feito com IA

São 7 conferências, cada uma com o passo a passo para você fazer sozinho, mesmo sem ser programador. Por Vinícius Fontes (@ovinifontes).

Antes de começar: faça tudo no seu próprio app, de preferência rodando no seu computador (localhost) ou em ambiente de teste, com contas e dados falsos. Testar o app de outra pessoa sem autorização é crime (Lei 12.737/2012).

01

Dados de um usuário visíveis para outro

O risco: alguém troca um número na URL e vê pedidos, saldo ou perfil de outra pessoa.

Como conferir

  1. Crie duas contas de teste, A e B. Abra a conta A numa janela normal e a conta B numa janela anônima.
  2. Na conta B, abra uma página com dados dela (perfil, pedido, histórico) e copie a URL. Se tiver um número ou código (ex.: /pedidos/123), é ele que importa.
  3. Cole essa URL na janela da conta A. Tente também trocar o número por vizinhos (123 → 124).
  4. Faça o mesmo com o que o app busca por trás: aperte F12, aba Network, recarregue a página e abra na janela de A os endereços com /api/ que tenham um ID.

Passou se: a conta A só vê “não encontrado” ou os próprios dados.

Usa Supabase? No painel, abra Advisors → Security Advisor. Tabela com RLS desligado pode ser lida por qualquer pessoa com a chave pública do seu app.

02

Chave secreta no navegador

O risco: a chave da API de IA ou de pagamento vai junto com o site, e qualquer um copia e gasta por sua conta.

Como conferir

  1. Abra o .env (ou .env.local) e leia só os nomes das variáveis. Nome começando com NEXT_PUBLIC_, VITE_ ou EXPO_PUBLIC_ vai para o navegador. Se um desses tiver KEY, SECRET, TOKEN ou PASSWORD no nome, desconfie.
  2. Com o app aberto no Chrome, aperte F12 (Mac: Cmd+Option+I), aba Sources, e busque em todos os arquivos com Ctrl+Shift+F (Mac: Cmd+Option+F). Cole os primeiros 8 a 10 caracteres de cada chave secreta.
  3. Na aba Network, use a parte do app que chama a IA ou o pagamento. Se o pedido sai do navegador direto para o provedor (ex.: api.openai.com, api.anthropic.com), a chave está no navegador. O certo é passar pelo seu servidor (ex.: /api/...).

Passou se: a busca não acha nenhuma chave secreta e nenhuma chamada paga sai direto do navegador. Chaves feitas para o navegador podem aparecer: a publicável da Stripe (pk_...) e a pública do Supabase (com RLS ligado).

Se falhou: gere uma chave nova no painel do provedor e apague a antiga. Só tirar do código não resolve: quem já abriu o app pode ter copiado.

03

Arquivo .env no GitHub

O risco: suas chaves ficam no repositório, às vezes num commit antigo que você nem lembra.

Como conferir (no terminal, na pasta do projeto)

git ls-files | grep -i "\.env"                     # arquivos .env versionados hoje
git log --all --oneline --name-only -- '*.env*'    # arquivos .env em qualquer commit antigo
git check-ignore -v .env.local                     # deve responder com a linha do .gitignore

Passou se: nos dois primeiros só aparece .env.example (sem valores reais) e o terceiro responde algo.

Se falhou: troque todas as chaves que estavam no arquivo. Apagar o arquivo ou o commit não desfaz: se o repositório já foi para o GitHub, considere as chaves vazadas.

04

Webhook que aceita qualquer aviso

O risco: alguém manda para o seu app um aviso falso de “pagamento confirmado” e ganha créditos ou plano de graça.

Como conferir (só localmente ou no modo de teste do seu provedor de pagamento)

  1. Faça uma compra de teste e pare antes de pagar. Anote o ID da cobrança pendente (aparece no painel de teste do provedor).
  2. Copie da documentação do provedor um exemplo do aviso de pagamento confirmado, troque o ID pelo da sua cobrança e salve como aviso-falso.json.
  3. Mande o aviso sem assinatura nenhuma:
curl -i -X POST "http://localhost:3000/<caminho-do-seu-webhook>" \
  -H "Content-Type: application/json" --data @aviso-falso.json

Passou se: a resposta é uma recusa (401, 403 ou 400) e nada muda: sem crédito, sem plano liberado, a cobrança continua pendente. Faça também uma compra de teste de verdade e reenvie o mesmo aviso pelo painel do provedor: o crédito cai uma vez só.

Se falhou: o webhook precisa conferir a assinatura ou o token do provedor antes de fazer qualquer coisa (veja a página de webhooks na documentação dele) e, de preferência, confirmar o pagamento na API do provedor antes de liberar.

05

Login sem limite de tentativas

O risco: alguém testa senha atrás de senha, ou usa o seu “esqueci a senha” e o link de login para lotar a caixa de e-mail de outra pessoa e gastar a sua cota.

Como conferir

Na sua tela de login, erre a senha 10 vezes seguidas, ou peça o link de login 10 vezes seguidas para um e-mail seu. Pelo terminal (troque o caminho e os campos pelos do seu app):

for i in $(seq 1 20); do
  curl -s -o /dev/null -w "%{http_code}\n" -X POST "http://localhost:3000/<caminho-do-login>" \
    -H "Content-Type: application/json" -d '{"email":"seu-email-de-teste@seudominio.com","password":"errada"}'
done

Passou se: depois de algumas tentativas o app recusa (código 429 ou “tente mais tarde”), e a mensagem é a mesma para e-mail cadastrado ou não. Login feito por serviço (Supabase Auth, Clerk, Firebase)? Procure “rate limit” no painel e confira os limites.

06

Dependências com falhas conhecidas

O risco: um pacote que o app usa tem uma falha já publicada.

Como conferir (na pasta do projeto)

npm audit --omit=dev     # se você usa npm
pnpm audit --prod        # se você usa pnpm

Passou se: nenhum alerta critical ou high nos pacotes de produção. Um alerta não prova que o seu app pode ser atacado, mas atualizar costuma ser barato.

Se falhou: atualize o pacote apontado (ou rode npm audit fix, sem --force) e teste o app de novo.

07

LGPD básica

O risco: você trata dados pessoais sem dizer como, e não consegue atender quem pede para ver ou apagar os próprios dados.

Como conferir

  1. Política de privacidade: tem link no rodapé, em português, e diz quais dados você coleta, para quê, com quais serviços compartilha (pagamento, e-mail, IA, hospedagem) e como a pessoa pede acesso ou exclusão.
  2. Excluir conta: crie uma conta de teste, peça a exclusão (botão ou e-mail) e confira no banco que os dados sumiram ou viraram anônimos. O que outra lei manda guardar (ex.: dados de nota fiscal) pode ficar, e a política diz isso.
  3. Logs sem dados pessoais: faça login e uma compra de teste, abra os logs do servidor (na Vercel, aba Logs; no EasyPanel, os logs do serviço) e busque o seu e-mail, CPF e telefone. Não deve aparecer nenhum.
  4. Coleta mínima: o cadastro só pede o que o app usa de verdade.

Isto não é orientação jurídica. Para o seu caso, fale com um advogado.

Passar em tudo não garante que o app é seguro. Este checklist reduz o risco nos pontos acima; o que você construir depois precisa ser conferido de novo.

O Kit SaaS BR, que estou montando, vem com essas proteções construídas e com teste automatizado. Prontas e testadas em 26/10/2026: cada usuário só vê os próprios dados, nenhuma chave secreta no navegador (com um check que falha se aparecer uma), assinatura conferida nos avisos de pagamento da AbacatePay e da Stripe, limite de tentativas no login e LGPD (baixar dados e excluir conta). Novidades em @ovinifontes.

Lista de espera

Sua ideia, pronta para cobrar.

Entre na lista e receba agora, grátis, o Pix + créditos funcionando. Quando as vendas abrirem, a lista tem 50 vagas de fundador a R$ 197.

Veja como usamos seus dados na Política de privacidade.