Segurança em SaaS: o que implementar antes de lançar

Uma falha de segurança logo após o lançamento pode encerrar um SaaS antes mesmo de ele ter a chance de provar seu valor. Não porque o ataque seja necessariamente catastrófico em escala — mas porque a reputação é o ativo mais frágil de um produto novo. Um vazamento de dados de clientes no primeiro mês de operação raramente é recuperável.

A boa notícia é que a maioria das vulnerabilidades exploradas em SaaS novos não são zero-days sofisticados. São falhas básicas e previsíveis: senhas sem limite de tentativas, tokens expostos em logs, ausência de validação de permissão em endpoints de API, dados sensíveis sem criptografia. Resolver essas vulnerabilidades antes do lançamento é trabalhoso, mas inteiramente factível.

Este guia cobre as cinco camadas de segurança que todo SaaS deve ter implementadas antes de receber os primeiros usuários reais.

Autenticação: MFA, Session Management e Brute Force

Autenticação é a porta de entrada — e a maioria dos ataques bem-sucedidos começa aqui. Implementar autenticação segura vai além de "verificar email e senha".

MFA (Multi-Factor Authentication):

Para SaaS B2B, MFA não é opcional — é esperado. Clientes corporativos frequentemente exigem suporte a TOTP (Google Authenticator, Authy) como requisito de segurança. A implementação pode ser feita com bibliotecas como otplib (Node.js) em menos de um dia.

import { authenticator } from 'otplib';
import { toDataURL } from 'qrcode';

// Gerar secret e QR Code para o usuário configurar o MFA
async function setupMFA(userId: string) {
  const secret = authenticator.generateSecret();
  const otpauth = authenticator.keyuri(userEmail, 'MeuSaaS', secret);
  const qrCodeUrl = await toDataURL(otpauth);

  // Salvar secret criptografado no banco (nunca em texto plano)
  await db.user.update({
    where: { id: userId },
    data: { mfaSecret: encrypt(secret), mfaEnabled: false }, // ativa apenas após verificação
  });

  return { qrCodeUrl, secret };
}

// Verificar código TOTP no login
function verifyMFAToken(secret: string, token: string): boolean {
  return authenticator.check(token, secret);
}

Proteção contra brute force:

Todo endpoint de login precisa de rate limiting específico por IP e por email. Sem isso, ferramentas automatizadas testam milhares de senhas em segundos.

// Rate limiting no endpoint de login
import rateLimit from 'express-rate-limit';

const loginLimiter = rateLimit({
  windowMs: 15 * 60 * 1000, // janela de 15 minutos
  max: 5,                    // máximo 5 tentativas por IP
  message: 'Muitas tentativas. Tente novamente em 15 minutos.',
  standardHeaders: true,
  legacyHeaders: false,
});

app.post('/auth/login', loginLimiter, handleLogin);

Session Management:

• Tokens JWT com expiração de 15 a 60 minutos para access tokens
• Refresh tokens com rotação — cada uso invalida o anterior
• Revogação de sessão ao trocar senha ou ao detectar atividade suspeita
• HttpOnly cookies para armazenar tokens no browser (nunca localStorage para access tokens sensíveis)

Autorização: RBAC e Princípio do Menor Privilégio

Autenticação verifica quem é o usuário. Autorização verifica o que ele pode fazer. São problemas diferentes, e confundi-los é uma das fontes mais comuns de vulnerabilidades em SaaS.

RBAC (Role-Based Access Control):

Implemente roles claras desde o início. Para a maioria dos SaaS B2B, três roles são suficientes no MVP:

Role	Permissões típicas
Owner	Tudo, incluindo billing e excluir organização
Admin	Gerenciar membros, configurações, todos os dados
Member	Criar e editar próprios registros, visualizar da equipe
Viewer (opcional)	Apenas leitura

Verificação de permissão em TODOS os endpoints:

O erro mais comum é verificar autenticação (o usuário está logado?) mas não verificar autorização (o usuário tem permissão para este recurso específico?). Um membro com acesso à organização A nunca deve conseguir ler ou modificar dados da organização B — mesmo autenticado.

// Middleware de autorização por recurso
async function requireOrganizationAccess(
  req: Request,
  res: Response,
  next: NextFunction
) {
  const { organizationId } = req.params;
  const userId = req.user.id;

  const membership = await db.organizationMember.findUnique({
    where: { organizationId_userId: { organizationId, userId } },
  });

  if (!membership) {
    return res.status(403).json({ error: 'Acesso negado' });
  }

  req.membership = membership; // role disponível para o handler
  next();
}

Princípio do menor privilégio:

Cada serviço, usuário de banco de dados e token de API deve ter apenas as permissões mínimas necessárias para sua função. O usuário de banco usado pela aplicação não precisa de DROP TABLE. A API key de integração de um serviço terceiro não precisa de acesso a dados de billing.

Criptografia: Dados em Repouso e em Trânsito

Em trânsito: HTTPS obrigatório em todos os endpoints. Sem exceções. Configure HSTS (HTTP Strict Transport Security) para forçar HTTPS mesmo se alguém tentar acessar via HTTP. No Vercel e na maioria dos provedores modernos, HTTPS é automático — mas verifique explicitamente.

Em repouso: Nem todos os dados precisam de criptografia no banco, mas dados sensíveis sim:

• Senhas: nunca armazene senha em texto plano ou com criptografia reversível. Use bcrypt, Argon2 ou scrypt com salt
• Segredos de MFA e API keys: criptografia simétrica com chave gerenciada fora do banco (AWS KMS, Vault, variável de ambiente)
• Dados pessoais sensíveis (CPF, dados de saúde, financeiros): criptografia em nível de campo quando exigido por LGPD/GDPR

// Criptografia de campo com AES-256-GCM
import { createCipheriv, createDecipheriv, randomBytes } from 'crypto';

const ALGORITHM = 'aes-256-gcm';
const KEY = Buffer.from(process.env.ENCRYPTION_KEY!, 'hex'); // 32 bytes

export function encrypt(text: string): string {
  const iv = randomBytes(16);
  const cipher = createCipheriv(ALGORITHM, KEY, iv);
  const encrypted = Buffer.concat([cipher.update(text, 'utf8'), cipher.final()]);
  const tag = cipher.getAuthTag();
  return `${iv.toString('hex')}:${tag.toString('hex')}:${encrypted.toString('hex')}`;
}

export function decrypt(data: string): string {
  const [ivHex, tagHex, encryptedHex] = data.split(':');
  const decipher = createDecipheriv(ALGORITHM, KEY, Buffer.from(ivHex, 'hex'));
  decipher.setAuthTag(Buffer.from(tagHex, 'hex'));
  return decipher.update(Buffer.from(encryptedHex, 'hex')) + decipher.final('utf8');
}

Rate Limiting, WAF e Headers de Segurança

Rate limiting em todas as rotas públicas:

Não apenas no login. Endpoints de criação de conta, recuperação de senha, envio de convites, qualquer rota que possa ser abusada por automação precisa de rate limiting.

Headers de segurança HTTP:

Uma configuração completa de headers de segurança é implementada em minutos e bloqueia toda uma classe de ataques (XSS, clickjacking, MIME sniffing):

// next.config.js — headers de segurança
const securityHeaders = [
  { key: 'X-DNS-Prefetch-Control', value: 'on' },
  { key: 'Strict-Transport-Security', value: 'max-age=63072000; includeSubDomains; preload' },
  { key: 'X-Frame-Options', value: 'SAMEORIGIN' },
  { key: 'X-Content-Type-Options', value: 'nosniff' },
  { key: 'Referrer-Policy', value: 'strict-origin-when-cross-origin' },
  { key: 'Permissions-Policy', value: 'camera=(), microphone=(), geolocation=()' },
  {
    key: 'Content-Security-Policy',
    value: "default-src 'self'; script-src 'self' 'unsafe-eval' 'unsafe-inline'; ...",
  },
];

Auditoria de logs:

Antes de lançar, implemente logging de eventos de segurança: logins bem-sucedidos e falhados, mudanças de permissão, acessos a dados sensíveis, operações de billing. Não para monitorar usuários — para detectar anomalias e ter evidência em caso de incidente.

Checklist de segurança pré-lançamento resumido:

Item	Prioridade
HTTPS + HSTS em todos os endpoints	Obrigatório
Rate limiting em login e rotas públicas	Obrigatório
Senhas com bcrypt/Argon2	Obrigatório
Verificação de autorização em todos os endpoints	Obrigatório
Headers de segurança HTTP configurados	Obrigatório
Variáveis de ambiente nunca no repositório	Obrigatório
MFA disponível (não obrigatório no MVP)	Recomendado
Criptografia de campos sensíveis	Recomendado
Logs de auditoria de segurança	Recomendado
Scan de dependências (npm audit)	Recomendado

Conclusão com CTA

Segurança não é um recurso que se adiciona depois — é uma camada que permeia toda a arquitetura. Os itens obrigatórios desta lista levam de dois a quatro dias para implementar corretamente em um SaaS novo. São dias que valem anos de reputação protegida.

O custo de remediar uma falha de segurança após um incidente — notificação de clientes, potencial ANPD (Brasil) ou GDPR (Europa), retrabalho técnico emergencial — é ordens de grandeza maior do que o custo de implementar essas proteções antes do lançamento.

Na SystemForge, segurança é parte do checklist padrão de todo SaaS que entregamos: auth com MFA, RBAC implementado, headers configurados, criptografia de campos sensíveis e auditoria de logs prontos antes do primeiro deploy. Fale com a gente para construir seu SaaS com a segurança certa desde a fundação.