Antes de lançar seu SaaS ou app: 12 itens de segurança em 2026

Você está a poucas semanas de lançar seu app, SaaS, marketplace ou plataforma. A pressão pra colocar no ar é grande. Marketing apertando. Investidor querendo ver tração. E uma pergunta que ninguém da equipe consegue responder com tranquilidade: está seguro?

Esse texto é o checklist honesto. Os 12 itens abaixo são os mínimos que precisam estar resolvidos antes do primeiro cliente entrar no seu sistema. Cada item tem o nível de risco se ignorado, em linguagem que dono de empresa entende.

Como usar esse checklist

Marque cada item: ✅ resolvido / ⚠️ em progresso / ❌ esquecido. Itens marcados ❌ devem virar tarefa antes do lançamento. Itens ⚠️ precisam de prazo claro.

Se você ficar com 4+ itens em ❌, considere adiar o lançamento por 2–4 semanas. Bug grave em produção custa muito mais (em dinheiro, tempo e reputação) do que atraso planejado.

1. HTTPS funcionando em todos os endereços

O que é:seu site precisa abrir com cadeado verde no navegador, em todos os subdomínios. Sem isso, o navegador exibe aviso de “site não seguro” — Google penaliza, cliente desconfia.

Como verificar: abra o site, app.seudominio.com.br, api.seudominio.com.br. Cada um deve ter cadeado.

Risco se ignorar: 🔴 Alto. Hoje em dia, sem HTTPS, navegadores bloqueiam o acesso ou marcam como inseguro de forma agressiva. Lançar sem HTTPS = lançar errado.

2. Senhas fortes e autenticação multifator (2FA) na área administrativa

O que é: qualquer painel de administração (admin, backoffice, painel da equipe) precisa de 2FA obrigatório. Senha sozinha não basta.

Como verificar: tente entrar no admin como qualquer funcionário sem segundo fator. Se conseguir, você está vulnerável.

Risco se ignorar: 🔴 Alto. Senhas vazam toda semana em algum site. Funcionário usa senha igual em vários lugares (sempre). Sem 2FA, vazamento em qualquer lugar vira acesso ao seu sistema.

3. Banco de dados não pode estar acessível pela internet

O que é: seu banco (PostgreSQL, MySQL, MongoDB) precisa estar isolado — só sua aplicação fala com ele, não a internet aberta.

Como verificar: pergunte ao seu desenvolvedor: nosso banco está em VPC privada (rede privada)? Se ele hesitar, alerta.

Risco se ignorar: 🔴 Crítico. Banco de dados acessível direto pela internet = atacante encontra com scanner em minutos, tenta senhas comuns, e leva todos os seus dados. Vazamentos gigantes começam exatamente assim.

4. Chaves de API e senhas NÃO podem estar no código (GitHub)

O que é: chaves do Stripe, AWS, OpenAI, banco de dados — tudo isso precisa estar em variáveis de ambiente, nunca no código que vai pro Git.

Como verificar: peça ao desenvolvedor pra rodar ferramenta como git-secrets ou truffleHog no repositório. Ele te dá lista de tudo que está exposto.

Risco se ignorar: 🔴 Crítico. Atacantes monitoram GitHub público em tempo real procurando chaves vazadas. Tempo médio entre commit e exploração: alguns minutos. Em uma empresa SaaS pequena, basta uma chave AWS vazada pra ter conta de US$ 100.000 cobrada por mineração de cripto.

5. Backup automatizado, testado, em local separado

O que é: ter backup só na mesma cloud onde está a aplicação não conta — atacante derrubando a cloud derruba os dois. Backup tem que estar em provedor separado, com restore já testado.

Como verificar: pergunte ao dev: quando foi a última vez que vocês testaram restaurar de backup?Se a resposta for “nunca”, vocês têm cópia, mas não têm backup confiável.

Risco se ignorar: 🔴 Alto. Em ataque de ransomware, backup não testado é equivalente a não ter backup. Cerca de 1 em cada 3 organizações que pagam ransomware não recuperam todos os dados (Sophos, Veeam) — pagar não é solução.

6. Permissões corretas: cliente A NÃO pode ver dados do cliente B

O que é: em qualquer plataforma multi-cliente (SaaS, marketplace, app), o sistema precisa garantir que cada usuário só acessa o que é dele. Parece óbvio, mas é a falha #1 mais comum em APIs.

Como verificar: faça este teste — crie 2 contas com emails diferentes, em planos diferentes. Tente, na conta A, mudar a URL pra ver dados da conta B. Se conseguir, está vulnerável.

Risco se ignorar: 🔴 Crítico. Tem nome técnico (BOLA / IDOR), está em 1º lugar da lista das falhas mais comuns em APIs de 2026, e quase ninguém detecta antes do cliente denunciar.

7. Senhas dos usuários armazenadas com hash + salt (não em texto puro)

O que é:quando seu cliente cria conta com senha, você não pode guardar a senha “dele”. Você guarda uma versão embaralhada (hash). Padrão moderno: bcrypt, argon2 ouscrypt.

Como verificar:peça ao dev pra mostrar como ficam as senhas no banco. Se você vê “senha123”, está errado. Se vê sequência longa começando com $2b$ ou $argon2id$, está certo.

Risco se ignorar: 🔴 Catastrófico. Se um dia o banco vazar, e as senhas estiverem em texto puro: você acabou de entregar a senha que seu cliente usa em vários sites pro atacante. O dano vira global, não só do seu sistema.

8. Logs (registros) de quem acessou o quê, com retenção mínima de 90 dias

O que é: seu sistema precisa registrar quem fez login, quem mudou o quê, quem deletou o quê. Esses logs ajudam a entender se algo está errado e obrigam investigação após incidente.

Como verificar:“qual é nosso retenção de log de autenticação?” Se a resposta for “não temos” ou “7 dias”, alerta.

Risco se ignorar:🟡 Médio. Sem logs, em incidente você fica cego — não consegue responder “quem fez isso?”, e a ANPD pode considerar negligência.

9. Plano de resposta a incidente escrito (mesmo que simples)

O que é:documento de 2 a 5 páginas dizendo: “quando algo dá errado, fulano faz X, ciclano faz Y, beltrano avisa Z”. Não precisa ser complexo. Precisa existir.

Como verificar:pergunte: “temos plano de incidente?” Se receber silêncio, tem que escrever um.

Risco se ignorar: 🟡 Alto na hora do incidente. No momento da emergência, ninguém raciocina bem. Plano escrito antes = decisões certas tomadas em frio.

10. Limites de tentativa (rate limit) em pontos sensíveis

O que é: formulário de login não pode aceitar 1.000 tentativas por minuto. Cadastro não pode aceitar criação de 500 contas em 1 minuto. Senão, atacantes abusam até descobrir senha real ou criar contas falsas em massa.

Como verificar: tente errar a senha 20 vezes seguidas no seu próprio login. Se nunca te bloqueou, está sem rate limit.

Risco se ignorar:🟡 Alto. Atacantes usam “listas” de senhas comuns que vazaram em outros sites. Se você não bloqueia, eles testam todas em horas.

11. Política de privacidade e termos publicados (LGPD)

O que é: antes de você coletar qualquer dado pessoal de cliente, a LGPD exige que você publique: política de privacidade clara, termos de uso, e indique um Encarregado de Dados (DPO).

Como verificar: tente abrir seusite.com.br/privacidade. Se 404, falta. Se a política está desatualizada (cita CCPA, GDPR, mas não LGPD), está errada.

Risco se ignorar: 🟡 Alto. ANPD pode multar mesmo sem incidente, só pela falta de transparência. E cliente enterprise recusa contrato com fornecedor sem política pública.

12. Pentest formal antes do lançamento (terceiro independente)

O que é: antes do primeiro cliente real entrar, contratar empresa especializada em segurança ofensiva pra atacar a plataforma como atacante real. Não é a equipe de QA. Não é o desenvolvedor revisando o próprio código. É terceiro com olhar adversarial.

Como verificar: tem relatório de pentest formal recente, dos últimos 60 dias, escopo claramente definido, com PoC reproduzível das falhas?

Risco se ignorar:🔴 Crítico. Os 11 itens anteriores cobrem o “básico”. Pentest formal cobre as falhas específicas do seu sistema — falhas de lógica de negócio, chains de exploração, premissas erradas dos seus desenvolvedores. São essas que aparecem em vazamentos de notícia, não as 11 anteriores.

Resumo executivo: tabela de risco por item

Quanto custa fazer tudo isso direito

Estimativa realista para empresa lançando MVP/SaaS pequeno:

• Itens 1 a 11 (implementação técnica interna): 4 a 6 semanas de trabalho do time
• Item 12 (pentest externo): R$ 3.000 a R$ 8.000 — pode ser feito em paralelo com itens internos

Total típico: R$ 5.000 a R$ 15.000 + tempo de equipe.

Compare com o custo médio de incidente em SaaS recém-lançado: R$ 100.000 a R$ 800.000 (multas, processos, churn, refazer arquitetura, perda de credibilidade pra captar próxima rodada).

O que fazer agora

Se você está a 4–8 semanas do lançamento e ainda tem itens em ❌, a melhor decisão é:

1. Travar os itens 7 e 4 imediatamente (catastróficos)
2. Resolver itens 1, 2, 3 e 6 nos próximos 14 dias
3. Contratar pentest externo paralelamente — leva 2–4 semanas pra concluir
4. Restante (itens 5, 8, 9, 10, 11) nas semanas seguintes

Pentest pré-lançamento da No Vuln para SaaS pequeno custa entre R$ 3.000 e R$ 8.000, leva 2 a 3 semanas, e cobre exatamente os itens técnicos da lista acima + falhas específicas que você não consegue ver de dentro.

Marca uma call e a gente avalia em 30 minutos onde está sua plataforma e o que falta resolver antes do lançamento.