Checklist de Segurança SaaS Antes do Lançamento: 40 Verificações que Fazemos Primeiro (2026)

Checklist de Segurança SaaS Antes do Lançamento: 40 Verificações que Fazemos Primeiro (2026)

Uma checklist de segurança SaaS antes do lançamento vale mais do que uma pilha de emblemas de conformidade que ainda não tem. Eis a verdade desconfortável: a maioria das checklists de lançamento diz-lhe o que proteger, mas nunca mostra como. Esta inclui o código. Construímos sobre Next.js e Supabase, já vimos um único filtro tenant_id em falta permitir que uma conta de teste lesse os dados de outro cliente, e o relatório Cost of a Data Breach de 2024 da IBM colocou a média global em 4,88 milhões de dólares. Não precisa de SOC 2 para entrar em produção. Precisa da linha de base da camada de aplicação abaixo, agrupada, executável e mapeada para OWASP e NIST.

Pontos-Chave

• Não precisa de SOC 2 ou de um teste de penetração para lançar. Precisa da linha de base da camada de aplicação abaixo.
• O bug de lançamento mais perigoso é a fuga de dados entre inquilinos devido à falta de verificação de tenant_id.
• Nunca crie a sua própria autenticação. Use Auth.js, Clerk ou Supabase Auth.
• Audite os prefixos NEXT_PUBLIC_ antes de implementar. É a forma mais rápida de vazar um segredo.

Esta linha de base mapeia-se para o OWASP ASVS 5.0 e para o NIST Secure Software Development Framework (SSDF), as duas referências em que a Google mais confia para este tópico e, notavelmente, as duas que nenhum dos guias melhor classificados se preocupa em citar.

A Sua Checklist de Segurança Pré-Lançamento (Versão Rápida)

Estes são os requisitos mínimos de segurança antes de lançar, agrupados em seis categorias. Quarenta itens. Execute-os de cima para baixo, entregue as secções de código ao seu programador e trate qualquer item marcado como P0 na tabela de prioridades abaixo como um bloqueador de lançamento.

Segredos e Configuração

1. .env está no .gitignore desde o primeiro commit e nunca foi submetido.
2. Cada prefixo NEXT_PUBLIC_ e VITE_ é auditado; nada secreto vai para o navegador.
3. Os segredos do servidor residem num gestor (variáveis de ambiente da plataforma, AWS Secrets Manager, Vault), não no repositório.
4. Qualquer chave que tenha tocado no histórico do git é rodada antes do lançamento.
5. Nenhum segredo aparece em registos, payloads de erro ou no pacote do cliente.
6. Procurou chaves ativas no pacote construído (grep -r "sk_live" .next/).

Autenticação e Acesso

1. A autenticação é construída numa biblioteca (Auth.js, Clerk ou Supabase Auth), não feita à medida.
2. A MFA está disponível nas contas.
3. Os cookies de sessão definem Secure, HttpOnly e SameSite.
4. Nenhum JWT ou token de sessão é armazenado em localStorage.
5. RBAC e funções de privilégio mínimo são aplicados no lado do servidor, não apenas ocultados na IU.
6. As palavras-passe são hashadas com Argon2 ou bcrypt (apenas se gerir a autenticação internamente).
7. Os fluxos de reposição de palavra-passe e verificação de e-mail são testados contra abusos.

Dados e Inquilinos

1. Cada consulta inclui um filtro tenant_id.
2. O âmbito do inquilino é aplicado na camada ORM ou de repositório, não lembrado por consulta.
3. A segurança a nível de linha está ativada e os seus modos de falha são compreendidos.
4. Cada endpoint de ID de objeto executa uma verificação de propriedade (isto elimina IDOR).
5. tenant_id é incluído nas chaves de cache e nos caminhos de armazenamento de objetos.
6. Os dados são encriptados em repouso e em trânsito.
7. As assinaturas de pagamento e webhook (Stripe, etc.) são verificadas no lado do servidor.

Dependências e Cadeia de Abastecimento

1. npm audit ou pnpm audit está limpo de problemas altos e críticos (ou explicitamente triados).
2. Dependabot ou Renovate está ativado.
3. Snyk ou Socket executa SCA mais profunda, além de verificações de malware e licenças.
4. O ficheiro de bloqueio (lockfile) é submetido.
5. Não existem pacotes abandonados ou sem manutenção no caminho crítico.
6. As imagens de contentor são analisadas se utilizar Docker.

Rede e Transporte

1. HTTPS é imposto em todo o lado, com pré-carregamento HSTS.
2. Uma Política de Segurança de Conteúdo (CSP) está definida (apenas relatório primeiro, depois imposição).
3. X-Content-Type-Options: nosniff e X-Frame-Options/frame-ancestors estão definidos.
4. Referrer-Policy e Permissions-Policy estão definidos.
5. CORS usa uma lista de permissões, nunca * com credenciais.
6. A limitação de taxa protege a autenticação e endpoints dispendiosos.
7. Cada endpoint valida a entrada com um esquema (Zod ou similar).

Monitorização e Resposta

1. Registos de auditoria centralizados registam quem acedeu ao quê e quando.
2. O tratamento de erros nunca vaza rastros de pilha para os utilizadores.
3. Alertas disparam em anomalias de autenticação (picos de falhas de login, viagens impossíveis).
4. Cópias de segurança automatizadas correm e testou uma restauração.
5. Existe um contacto de resposta a incidentes e um manual de operações de uma página.
6. A monitorização de tempo de atividade e erros (Sentry ou equivalente) está ativa.
7. Sabe o gatilho para trazer um teste de penetração.

Prioridade de Correção Primeiro

Nem todos os itens bloqueiam o lançamento. Esta tabela de triagem ordena a linha de base pelo dano se for ignorada, para que um fundador saiba o que é inegociável. P0 = corrigir antes do lançamento, P1 = corrigir na primeira semana, P2 = corrigir dentro do trimestre.

Segredos e Configuração: Alguma Chave Está a Vazar para o Seu Pacote do Cliente?

Higiene de segredos no lançamento significa que nenhuma credencial chega ao navegador. O prefixo NEXT_PUBLIC_ no Next.js (e VITE_ no Vite) envia um valor para cada visitante, por isso um prefixo errado vaza uma chave. Mantenha .env fora do git, coloque os segredos do servidor num gestor e procure no seu resultado de compilação antes de implementar.

Eis a armadilha que vemos com mais frequência: NEXT_PUBLIC_ não significa "informação pública". Significa "estou literalmente a enviar isto para o navegador de cada visitante". Prefixe um segredo da Stripe ou uma chave de função de serviço dessa forma e ela estará ativa no pacote para qualquer pessoa que abra as Ferramentas de Programador.

# .env.local (the mistake)
NEXT_PUBLIC_STRIPE_SECRET=sk_live_51H...   # BAD: ships to every browser
STRIPE_SECRET_KEY=sk_live_51H...           # OK: server-only

# Public (safe to expose) vs server-only
NEXT_PUBLIC_SUPABASE_ANON_KEY=eyJ...       # anon key is meant to be public
SUPABASE_SERVICE_ROLE_KEY=eyJ...           # never NEXT_PUBLIC_ this

# Catch a leaked key before you deploy
grep -r "sk_live" .next/    # any hit means a secret is in your client bundle

O resto da linha de base de segredos é aborrecido e inegociável: .env no .gitignore desde o primeiro commit, segredos do servidor num gestor em vez do repositório, e a rotação de qualquer chave que tenha tocado no histórico do git (apagar um commit não anula o vazamento). Um token de implementação vazado é exatamente como começam violações como o incidente da Vercel, por isso trate cada token como se já estivesse na lista de vigilância de alguém.

Autenticação e Acesso: Deve Criar Autenticação ou Usar uma Biblioteca?

Deve criar autenticação ou usar uma biblioteca? Quase sempre use uma biblioteca. Auth.js, Clerk e Supabase Auth absorveram anos de casos extremos que de outra forma redescobriria em produção: fixação de sessão, revogação de token, abuso do fluxo de reposição. Criar a sua própria só é defensável com um engenheiro de segurança e uma razão pela qual nenhum fornecedor serve, o que é raro.

Criar a sua própria autenticação é a forma mais cara de poupar 25 dólares por mês. Eis como as opções honestas se comparam.

Duas armadilhas afundam equipas que escolhem uma biblioteca mas saltam a configuração. Primeiro, a revogação de JWT é genuinamente difícil, por isso um token roubado permanece válido até expirar; mantenha a vida útil dos tokens curta e prefira sessões do lado do servidor para qualquer coisa sensível. Segundo, tokens em localStorage podem ser roubados por qualquer payload XSS, por isso armazene sessões em cookies httpOnly com Secure e SameSite. Aplique RBAC no servidor, não ocultando botões na IU.

Se o seu SaaS incluir uma funcionalidade de IA ou LLM, trate a entrada do modelo como uma fronteira de autenticação não confiável também. Consulte o nosso guia para prevenir injeção de prompts, porque um assistente libertado com acesso a ferramentas é um problema de controlo de acesso vestido de janela de chat.

Dados e Inquilinos: Como Impede Que Um Inquilino Leia os Dados de Outro?

Isolamento de inquilinos significa que cada consulta, chave de cache e caminho de armazenamento tem o âmbito do inquilino atual. Um filtro tenant_id em falta permite que um cliente leia os dados de outro, o bug de lançamento mais perigoso que existe. A segurança a nível de linha ajuda, mas é um cinto de segurança, não um campo de força, por isso adicione também verificações de propriedade em cada endpoint de ID de objeto.

Esta é a secção que nenhum concorrente cobre como código, e é a razão pela qual as fugas entre inquilinos deslizam para a produção. A correção começa por nunca confiar num ID por si só. Limite cada leitura ao inquilino do chamador e aplique-o na camada de dados para que ninguém tenha de se lembrar disso por consulta.

// BAD: no tenant scope. Any valid id returns any tenant's row.
const order = await db.order.findFirst({ where: { id } });

// GOOD: scoped to the caller's tenant on every read.
const order = await db.order.findFirst({
  where: { id, tenantId: session.tenantId },
});

A falha relacionada é IDOR (referência direta a objeto insegura), que o OWASP API Security Top 10 arquiva sob API1: Autorização de Nível de Objeto Quebrada. Uma conta de teste incrementa um ID no URL e lê um registo que nunca deveria ver. A Web Security Academy da PortSwigger tem um walkthrough completo de como os atacantes encontram estes. A correção é uma verificação de propriedade.

// GET /api/invoices/1234, a test account increments the id
// and reads another tenant's invoice. Classic BOLA.
const invoice = await db.invoice.findUnique({ where: { id } });

// Fix: verify ownership before you return anything.
if (invoice.tenantId !== session.tenantId) {
  return res.status(403).json({ error: "Forbidden" });
}

Eis o enquadramento que o mantém honesto: cada IDOR é uma falha de isolamento de inquilinos, mas nem toda falha de isolamento de inquilinos é um IDOR. A segurança a nível de linha do Postgres apanha muitos deles na base de dados, mas tem modos de falha silenciosa que vale a pena conhecer antes de depender dela.

-- Postgres RLS: a seatbelt, not a force field.
alter table orders enable row level security;

create policy tenant_isolation on orders
  using (tenant_id = current_setting('app.tenant_id')::uuid);
-- Silent-failure trap: forget to SET app.tenant_id on a pooled
-- connection and the policy reads the PREVIOUS request's tenant.

Contaminação de pools de ligação, fugas de contexto assíncrono e envenenamento de cache partilhada derrotam o RLS silenciosamente, razão pela qual a Folha de Dicas de Segurança Multi-Inquilino da OWASP lhe diz para prefixar chaves de cache e caminhos de armazenamento com o inquilino também. O capítulo de controlo de acesso do OWASP ASVS 5.0 e a documentação RLS do Supabase são as duas referências que vale a pena ler na íntegra aqui.

Dependências e Cadeia de Abastecimento: O Que Está Escondido nos Seus node_modules?

A sua aplicação só é tão segura quanto a sua dependência transitiva mais fraca. Execute npm audit ou pnpm audit no CI e falhe a compilação em descobertas altas ou críticas antes de lançar. Adicione Dependabot ou Renovate para atualizações automáticas, e Snyk ou Socket para verificações mais profundas de malware e licenças.

A armadilha é executar a auditoria uma vez manualmente, ver verde e nunca mais a executar. Ligue-a ao CI para que uma nova CVE num pacote que não tocou ainda bloqueie a fusão.

# .github/workflows/ci.yml: block the merge on high/critical
- name: Audit dependencies
  run: npm audit --audit-level=high    # non-zero exit fails the job

A documentação npm audit cobre os níveis de severidade e a flag --production se quiser ignorar descobertas apenas de desenvolvimento. A análise automatizada é o mínimo esperado, embora; para análise estática mais profunda que deteta cheiros de código e caminhos de injeção que um scanner de dependências perde, veja a nossa análise SonarQube. Submeta o seu ficheiro de bloqueio, elimine pacotes que não lançaram uma versão há anos e analise a sua imagem de contentor se implementar Docker.

Rede e Transporte: Quais Cabeçalhos de Segurança Precisa Realmente um SaaS?

Quais cabeçalhos de segurança precisa um SaaS? HTTPS mais HSTS e um conjunto curto de cabeçalhos fecham as lacunas mais fáceis de explorar. Adicione uma Política de Segurança de Conteúdo, uma lista de permissões CORS em vez de um wildcard, e limites de taxa na autenticação e endpoints dispendiosos. Valide cada entrada com um esquema como Zod para que payloads maus nunca cheguem à sua lógica.

Não precisa de cada cabeçalho já inventado. Precisa desta lista curta, e a referência de cabeçalhos de segurança MDN explica cada um em profundidade.

Defina os cabeçalhos uma vez, na borda, e adicione um limitador de taxa para que um script não possa forçar brutalmente a sua rota de login toda a noite.

// next.config.js: security headers on every response
const securityHeaders = [
  { key: "Strict-Transport-Security", value: "max-age=63072000; includeSubDomains; preload" },
  { key: "X-Content-Type-Options", value: "nosniff" },
  { key: "X-Frame-Options", value: "DENY" },
  { key: "Referrer-Policy", value: "strict-origin-when-cross-origin" },
];
// Rate-limit auth routes (Upstash example)
const { success } = await ratelimit.limit(ip);
if (!success) return new Response("Too many requests", { status: 429 });

Comece a sua CSP em modo apenas-relatório para não partir a sua própria aplicação, observe os relatórios de violação durante alguns dias e depois mude para imposição. Mantenha o CORS numa lista de permissões nomeada e nunca emparelhe * com credenciais.

Monitorização e Resposta: Como Saberá Se Foi Violado?

Não pode responder ao que não vê. Antes do lançamento, ligue registos de auditoria centralizados, alertas em anomalias de autenticação como picos de falhas de login, cópias de segurança automatizadas com uma restauração testada e um manual de operações de incidente de uma página. Uma cópia de segurança não testada é uma esperança, não uma cópia de segurança, e a altura de escrever o manual é agora, não a meio do incidente.

Os dados da IBM colocam o tempo médio para identificar e conter uma violação em 258 dias, e não pode reduzir esse número se os seus registos não registarem quem tocou no quê. Centralize-os, alerte sobre as anomalias que importam (picos de falhas de login, logins de viagem impossível, volume súbito de exportação) e certifique-se de que o seu manipulador de erros devolve uma mensagem limpa em vez de um rasto de pilha que mapeia os seus internos.

A deteção moderna de violações apoia-se na monitorização de anomalias em vez de regras estáticas; há mais sobre como isso realmente funciona no nosso artigo sobre como a IA previne violações de dados. Para o suporte do framework, o NIST SSDF (SP 800-218) delineia as práticas de resposta e monitorização em linguagem clara. Teste uma restauração antes do lançamento, não depois da sua base de dados desaparecer.

O Que Realmente Encontramos Quando Revimos Os Nossos Próprios Lançamentos

Quando a nossa equipa executa uma passagem de segurança pré-lançamento numa compilação, nossa ou de um cliente, duas falhas aparecem mais do que qualquer outra coisa. Primeira: um segredo a entrar no navegador num prefixo NEXT_PUBLIC_, geralmente uma chave de API de terceiros que alguém prefixou para fazer uma chamada do lado do cliente funcionar. Segunda: pelo menos um endpoint a faltar o seu âmbito tenant_id ou uma verificação de propriedade.

A falha de âmbito do inquilino é a assustadora porque a aplicação parece bem. Cada página carrega. O bug só aparece quando alguém muda um ID no URL. Numa revisão, GET /api/orders/:id devolveu qualquer encomenda a qualquer utilizador com sessão iniciada; uma conta de teste leu as encomendas de outro inquilino incrementando o número. A correção foram duas linhas: comparar order.tenantId com session.tenantId antes de devolver.

Não lhe vamos citar uma taxa de deteção falsa aqui. O que é honesto e repetível é isto: a fuga NEXT_PUBLIC_ e o âmbito de inquilino em falta são as duas coisas que encontramos em quase todas as revisões de primeira passagem, e ambas são baratas de corrigir assim que sabe onde procurar. É exatamente por isso que a checklist as coloca em primeiro lugar como P0.

Se preferir que uma equipa execute esta passagem por si antes do dia do lançamento, esse é o trabalho que fazemos. Obtenha uma revisão de segurança pré-lançamento →

Sobre o Autor

Mert Batur Gurbuz é Co-Fundador da Techsy.io, onde a equipa lança agentes de IA, sistemas de automação e pipelines de voz/SDR para clientes B2B. Estuda na Universidade de Birmingham e escreve sobre a stack de ferramentas LLM que a equipa da Techsy realmente usa em produção. Conecte-se no LinkedIn.

Perguntas Frequentes

O que deve estar numa checklist de segurança SaaS antes do lançamento?

Seis categorias: segredos e configuração (mantenha chaves fora do pacote do cliente), autenticação e acesso (use uma biblioteca, adicione MFA), dados e inquilinos (âmbito tenant_id mais verificações de propriedade), dependências (npm audit no CI), rede e transporte (HTTPS, HSTS, CSP, limites de taxa) e monitorização e resposta (registos de auditoria, cópias de segurança testadas, um manual).

O meu SaaS está suficientemente seguro para lançar?

Está pronto quando a linha de base P0 estiver concluída: segredos fora do pacote do cliente, isolamento de inquilinos em cada consulta, autenticação numa biblioteca, HTTPS com cabeçalhos de segurança e uma varredura de dependências limpa. A perfeição não é a barra. Uma aplicação lançada e monitorizada com a linha de base coberta supera uma "perfeita" que nunca lança.

Preciso de um teste de penetração antes de lançar um SaaS?

Não para lançar legalmente. Priorize um se lidar com pagamentos ou PII, visar compradores empresariais, ou se um auditor ou investidor pedir. Na fase MVP, gaste esse esforço na linha de base da camada de aplicação e no OWASP Top 10 primeiro. Um teste de penetração encontra mais quando as lacunas óbvias de IDOR e cabeçalhos já estão fechadas.

Preciso de SOC 2 para lançar um SaaS?

Não. Nenhum cliente espera SOC 2 de uma startup que lançou na semana passada. É um desbloqueio de vendas empresariais, não um portão de lançamento, e leva meses. Lance com a linha de base da camada de aplicação e depois inicie o processo SOC 2 quando um verdadeiro negócio empresarial precisar dele, não antes.

Devo construir a minha própria autenticação ou usar uma biblioteca como Auth.js, Clerk ou Supabase Auth?

Quase sempre use uma biblioteca. Auth.js, Clerk e Supabase Auth lidaram com os casos extremos de sessão, token e fluxo de reposição que causam a maioria dos bugs de autenticação feitos por conta própria. Criar a sua própria só é defensável se tiver um engenheiro de segurança e um requisito rígido que nenhum fornecedor satisfaça, o que é genuinamente raro.

Como mantenho os segredos fora do meu pacote do cliente?

Audite cada prefixo NEXT_PUBLIC_ e VITE_, porque qualquer coisa com esse prefixo vai para o navegador. Mantenha .env fora do git desde o primeiro commit, armazene segredos do servidor num gestor e procure no seu pacote construído (grep -r "sk_live" .next/) antes de implementar para detetar uma chave vazada.

Como isolo dados de inquilinos num SaaS multi-inquilino?

Coloque um filtro tenant_id em cada consulta e aplique-o na camada ORM ou de repositório para que seja automático. Ative a segurança a nível de linha e aprenda os seus modos de falha (contaminação de pool, fugas assíncronas). Adicione uma verificação de propriedade a cada endpoint de ID de objeto para fechar IDOR e delimite chaves de cache e caminhos de armazenamento por inquilino.

Quais cabeçalhos de segurança precisa um SaaS antes do lançamento?

No mínimo: Strict-Transport-Security (HSTS), uma Content-Security-Policy, X-Content-Type-Options: nosniff, X-Frame-Options ou frame-ancestors, Referrer-Policy e Permissions-Policy. Comece a sua CSP em modo apenas-relatório, reveja as violações e depois imponha-a. A documentação de cabeçalhos de segurança MDN lista valores recomendados para cada um, e a tabela de cabeçalhos acima resume o que cada um impede.

A análise automatizada como npm audit ou Snyk é suficiente?

Necessária mas não suficiente. Ferramentas como npm audit, Snyk e Socket detetam CVEs conhecidas e pacotes maliciosos, mas não conseguem encontrar falhas de lógica de negócio e controlo de acesso como IDOR ou um âmbito de inquilino em falta. Essas precisam de um humano, uma conta de teste e uma verificação explícita de propriedade. Execute ambos: o scanner e uma passagem manual.

A Conclusão: Uma Checklist de Segurança SaaS Que Realmente Pode Lançar

Não precisa de ser perfeito para lançar. Precisa da linha de base. Feche os itens P0 primeiro: segredos fora do pacote, isolamento de inquilinos em cada consulta, uma verificação de propriedade em cada endpoint de objeto, autenticação numa biblioteca e HTTPS com cabeçalhos. Se corrigir uma coisa antes do lançamento de sexta-feira, faça-o no isolamento de inquilinos, porque esse é o bug que vaza os dados de um cliente sem aviso prévio.

Tudo aqui é executável hoje, e nada disso requer um orçamento de conformidade. Trabalhe através das 40 verificações, entregue as secções de código ao seu programador e lance. Quer um segundo par de olhos antes de entrar em produção? Obtenha uma consulta gratuita e percorreremos a lista consigo.