// docs / security guides / pre-launch SaaS

Checklist de segurança pré-lançamento SaaS: 35+ itens

Faltam poucos dias para você lançar um produto SaaS desenvolvido com Cursor, Claude Code, Lovable ou Bolt. Esta lista de verificação é uma auditoria go/no-go que cobre as superfícies de segurança que as ferramentas AI falham consistentemente e que os fundadores que enviam rapidamente precisam abordar antes de receber o dinheiro do cliente. Oito seções, mais de 35 itens, cada um resolvido em 30 a 90 minutos. Imprima, risque e implante com confiança.

Cada item abaixo é essencial. Verde significa enviado e verificado; vermelho significa lançamento não resolvido e bloqueando. Para um passo a passo mais longo de cada categoria com trechos de código e padrões de falha reais, consulte How to secure an app built with AI coding tools e The vibe coding security checklist.

Isolamento de dados do cliente

Em um SaaS multilocatário, seu primeiro limite de segurança é o isolamento de dados. Os dados de cada cliente devem ser inacessíveis a todos os outros clientes, aplicados na camada de banco de dados, não na camada de aplicação.

Habilite a segurança em nível de linha (RLS) em cada tabela Supabase com ALTER TABLE public.table_name ENABLE ROW LEVEL SECURITY; ALTER TABLE public.table_name FORCE ROW LEVEL SECURITY;. FORCE evita que o proprietário da tabela a ignore.
Para cada política RLS, verifique os escopos de predicado para o usuário ou organização autenticado. Exemplo: CREATE POLICY "users_see_own" ON public.items FOR SELECT USING (auth.uid() = user_id);. Teste com uma segunda conta de usuário para confirmar se os dados permanecem isolados.
Se estiver usando Firebase / Firestore, as regras deverão corresponder ao seu modelo de locatário. Não use allow read, write: if true; ou regras de teste com limite de tempo. Use allow read, write: if request.auth.uid == resource.data.owner_uid; ou correspondência equivalente no escopo organizacional.
Use URLs assinados ou tokens de curta duração para acesso a arquivos, nunca buckets públicos. Supabase Armazenamento: defina ENABLE ROW LEVEL SECURITY na tabela objects e crie políticas que abrangem o acesso ao arquivo para o usuário autenticado. Teste downloads como usuários diferentes.
Na sua camada API, cada solicitação deve incluir auth.uid() ou contexto org-id. Cada consulta ao banco de dados deve ser filtrada por esse contexto. Exemplo: não SELECT * FROM items WHERE id = $1; sempre SELECT * FROM items WHERE id = $1 AND user_id = auth.uid().

Faturamento e pagamento

Stripe integração é onde a confiança do cliente encontra a segurança financeira. A configuração incorreta aqui significa pagamentos roubados, ciclos de reembolso ou perda de receita.

Use live Stripe keys na produção. Teste com uma chave de modo de teste separada na preparação. Nunca mude de teste para ativo sem uma varredura final no modo ao vivo.
Verifique a assinatura do webhook em cada evento de entrada: const event = stripe.webhooks.constructEvent(req.body, sig, webhookSecret);. Jogue se a assinatura falhar. Armazene o segredo do webhook apenas em uma variável de ambiente, nunca em código.
Implemente idempotência em manipuladores de webhook usando uma tabela de banco de dados codificada por event.id. Se o mesmo webhook chegar duas vezes (vai), a segunda execução será autônoma. Escreva a linha de idempotência na mesma transação da mudança de estado.
Em customer.subscription.updated e customer.subscription.deleted, revogue imediatamente o acesso. Não espere por um cron. Teste cancelando uma assinatura no Stripe Dashboard e verificando se o usuário está bloqueado em 5 segundos.
Armazene apenas o cliente Stripe ID e a assinatura ID em seu banco de dados, nunca o cartão completo ou a chave API. Recuperar o estado da assinatura ao vivo de Stripe em cada limite de autenticação (carregamento de página, chamada API, verificação de cron). Não armazene em cache o status da assinatura por mais de 1 minuto.

Autenticação e sessões

Auth é o alvo do invasor de segunda ordem em SaaS. Uma conta de usuário é um vetor de dados e métodos de pagamento.

Use supabase.auth.getUser() em todas as rotas protegidas, nunca getSession(). getSession() lê um cookie não verificado; getUser() valida o JWT lado do servidor. Em Next.js: const { data: { user } } = await supabase.auth.getUser(); antes de veicular conteúdo protegido.
Defina SameSite=Lax em cookies de autenticação (Supabase Auth faz isso por padrão). Verifique em DevTools → Aplicativo → Cookies. Se você vir SameSite=None, adicione sameSite: 'Lax' à configuração da sua sessão.
Habilite MFA em sua própria conta de administrador. Para MFA voltado para o usuário, teste-o de ponta a ponta antes do lançamento: inscreva-se, registre um dispositivo TOTP, saia, faça login novamente com o token TOTP e verifique se funciona.
Os tokens Magic-link devem expirar em 15 minutos. Os tokens de redefinição de senha devem expirar em 1 hora. Os tokens de sessão (JWTs) podem durar mais (24h-7d), mas devem ser validados a cada uso. Verifique os padrões do seu provedor de autenticação.
Teste a conclusão da saída: depois que um usuário clica em sair, o navegador exclui a sessão de autenticação, o servidor revoga todos os tokens e o usuário não pode acessar páginas protegidas. Em Supabase: ligue para await supabase.auth.signOut() e verifique se JWT não é mais válido na próxima solicitação.

PII e conformidade

Se você coletar e-mail, nome, informações de pagamento ou qualquer PII, você terá obrigações legais: minimização de dados, armazenamento seguro, exclusão sob demanda e prontidão DPA.

Escreva e publique uma política de privacidade (não opcional, mesmo para SaaS independente). Indique quais dados você coleta, por que, por quanto tempo os mantém e os direitos do usuário (acesso, correção, exclusão). Use um modelo do Termly ou similar, mas personalize-o.
Implemente um endpoint delete-account API que limpe PII do banco de dados. Teste: crie uma conta, adicione dados, exclua a conta, verifique se os dados desapareceram (use a inspeção direta do banco de dados).
Para conformidade com GDPR / CCPA, responda às solicitações do titular dos dados (acesso/correção/exclusão) no prazo de 30 dias. Documente seu processo. Se seu aplicativo for baseado em EU- ou atender usuários EU, um Adendo de processamento de dados Pro (DPA) com Stripe, Supabase e qualquer processador será necessário.
Criptografe campos confidenciais em repouso (as senhas são criptografadas por seu provedor de autenticação; mas tokenização de cartão de crédito, chaves API e segredos devem usar pgcrypto ou um cofre externo). Nunca armazene números de cartão de crédito em texto simples (em vez disso, use a tokenização Stripe).

Prontidão operacional

A segurança é contínua. A resposta a incidentes, o monitoramento e os runbooks começam antes do primeiro dia.

Configure uma página de status (Statuspage.io, Uptime Robot ou um simples index.html). Os clientes precisam saber se você está tendo uma interrupção. Atualize-o em cada incidente.
Tenha uma rotação de plantão documentada e testada. Quem acorda com alerta às 2 da manhã? Quem tem chaves de implantação? Quem pode revogar um token comprometido? Documente-o e execute um exercício de simulação de incêndio antes do lançamento.
Escreva um manual de resposta a incidentes de segurança: o que fazer se um cliente relatar uma violação, se você perder uma chave, se um serviço cair. Distribua para sua equipe. Teste um cenário (e.g., simule um vazamento de chave) para verificar se o plano funciona.
Os procedimentos de backup e restauração devem ser testados e não teóricos. Você pode restaurar a partir de backups? Cronometrar. Supabase: habilite backups automatizados (retenção de 7 dias no gratuito e 30 dias no pago). Teste uma restauração em um projeto separado trimestralmente.
Habilite o registro de auditoria para operações privilegiadas: Stripe logins no painel, Supabase chamadas de administrador API, alterações no esquema do banco de dados, reconciliação de pagamentos. Ferramentas: CloudTrail (AWS), Supabase registros de auditoria, extensão PostgreSQL pgaudit.

Superfície de ataque externa

Seu limite API está sob constante verificação de invasores. Bloqueie-o antes que o tráfego malicioso chegue.

Limite de taxa em cada endpoint público. Exemplo: 100 solicitações por minuto por IP na inscrição, 10 por minuto na redefinição de senha. Use Vercel KV, Redis ou similar. Falha com 429 (muitas solicitações).
Adicione CAPTCHA (hCaptcha ou reCAPTCHA) aos endpoints de inscrição e redefinição de senha para derrotar bots. Verifique o token do lado do servidor antes de aceitar a solicitação.
Use um WAF (Firewall de Aplicativo Web), se disponível: Cloudflare, Vercel Firewall de Aplicativo Web ou AWS WAF. Bloqueie automaticamente IPs e padrões maliciosos conhecidos.
Procure pontos de extremidade API abertos. Execute uma varredura passiva FixVibe em seu domínio de produção mensalmente. Revise as descobertas de rotas de depuração expostas, introspecção GraphQL, vazamento de chave API ou exposição de configuração.
Alterne credenciais (API chaves, OAuth tokens, senhas de banco de dados) trimestralmente. Documente o procedimento de rotação e automatize-o sempre que possível.

Observabilidade e registro

Quando as coisas dão errado, os logs são o seu registro forense. Configure-os desde o primeiro dia.

Centralize logs: Supabase Logs, Vercel Logs, logs de aplicativos e logs de autenticação em um único painel (Datadog, LogRocket ou auto-hospedado ELK). Pesquisável, retido por pelo menos 90 dias.
Alerta sobre eventos de segurança: logins com falha repetida (possível controle de conta), uso incomum de API (possível scraping), picos de erros (possível ataque ou incidente legítimo). Defina limites e integrações com o Slack.
Emita logs de auditoria para cada operação privilegiada: alterações de função de usuário, criação de nova conta de administrador, adições de métodos de pagamento, alterações de escopo em chaves API. Armazene-os separadamente dos logs do aplicativo com retenção imutável.

Verificação final

Antes de anunciar, execute uma verificação FixVibe completa e analise as descobertas com atenção de segurança.

Execute uma verificação ativa FixVibe Pro em seu domínio de produção. Configure seu domínio para teste ativo (DNS TXT ou HTTP verificação de arquivo). Autorize a verificação e analise todas as descobertas, especialmente as críticas e de alta gravidade. Corrija ou aceite cada um explicitamente.
Habilite novas verificações agendadas: Pro plano → 3h, 6h, 12h ou diariamente. Plano Unlimited → 6h, 12h, diariamente, a cada 2 dias ou semanalmente. Emparelhe com verificações active IDOR walking, SQL injection e reflected XSS em seu domínio verificado.
Configure webhooks: conecte FixVibe ao Slack ou envie um e-mail para que descobertas críticas acionem alertas em tempo real. Consulte /docs/webhooks para configuração.
Faça uma revisão manual final do código com foco nas pegadinhas em /docs/security-guides/ai-generated-code-security-scanner: segredos em pacotes, RLS/rules, limites de autenticação, CSP, posicionamento de middleware. Use vibe coding security checklist como modelo de revisão.

Dia de lançamento

Você limpou a lista de verificação. Implante com confiança. Após o lançamento, monitore ativamente: verifique FixVibe as descobertas diariamente durante a primeira semana, responda aos alertas dentro de 1 hora e mantenha o cronograma de verificação em execução. Para obter um guia de proteção passo a passo com trechos de código, consulte How to secure an app built with AI coding tools.