7 erros de isolamento de dados que ameaçam seu SaaS multi-tenant

Introdução

Um desenvolvedor independente que já entregou 40 aplicações SaaS multi-tenant compartilhou os 7 tipos de bugs de isolamento de dados que continuam aparecendo, mesmo em projetos de profissionais experientes. Lin Feng documentou no dev.to os erros mais comuns que podem expor informações de um cliente para outro, o tipo de falha que destrói a confiança e pode acabar com um negócio.

O relato chama atenção porque não trata de erros de iniciante. São problemas que surgem em código de produção, escritos por desenvolvedores que conhecem as boas práticas mas enfrentam a complexidade real de manter dados separados quando vários clientes usam a mesma infraestrutura. A experiência de Feng oferece um mapa dos pontos onde a segurança de dados costuma falhar, mesmo quando você acha que está fazendo tudo certo.

Vazamento por queries sem filtro de tenant é o erro número um

O problema mais frequente acontece quando você esquece de adicionar o filtro de tenant_id em uma query SQL. Parece básico, mas é exatamente o tipo de erro que passa em code review e chega em produção.

Feng explica que isso acontece principalmente em features novas ou em queries complexas com múltiplos joins. Você adiciona uma funcionalidade, testa com seu usuário de desenvolvimento e funciona perfeitamente, porque você só tem dados de um tenant no ambiente local.

O bug só aparece em produção, quando Cliente A faz uma busca e recebe resultados que incluem dados do Cliente B. Em sistemas com milhares de registros, esse tipo de vazamento pode passar despercebido por semanas.

Middlewares mal configurados expõem rotas inteiras

O segundo erro crítico envolve middlewares de autenticação que não cobrem todas as rotas. Você configura proteção para os endpoints principais mas esquece de uma rota de API usada por um webhook ou integração.

Segundo Feng, isso é especialmente comum quando você usa frameworks como Express ou FastAPI e adiciona rotas incrementalmente. Uma rota que deveria estar protegida por tenant isolation fica exposta porque o middleware não foi aplicado corretamente.

O desenvolvedor relata casos onde rotas de export de dados, relatórios ou webhooks ficaram acessíveis sem validação de tenant. Qualquer usuário autenticado podia acessar dados de qualquer cliente apenas mudando um parâmetro na URL.

Cache compartilhado mistura dados entre clientes

Problemas de cache representam o terceiro tipo de bug mais comum. Você implementa cache com Redis ou Memcached para melhorar performance, mas usa chaves que não incluem o tenant_id.

Feng descreve um cenário típico: Cliente A carrega um dashboard e os dados ficam em cache. Cliente B acessa o mesmo dashboard segundos depois e recebe os dados do Cliente A diretamente do cache, sem passar pela validação de tenant.

O problema piora quando você usa ferramentas como Vercel ou outros serviços de edge caching sem configurar corretamente as regras de separação por tenant. Cache é essencial para performance de SaaS, mas precisa de chaves únicas por cliente.

Background jobs processam dados do tenant errado

O quarto erro acontece em workers e filas de processamento assíncrono. Você enfileira um job para processar dados de um tenant, mas o worker não valida corretamente qual tenant deve processar.

Segundo o desenvolvedor, isso é comum em sistemas que usam Sidekiq, Bull ou outras bibliotecas de job queue. O job recebe um ID de registro para processar, mas não valida se aquele registro pertence ao tenant correto antes de executar.

Feng menciona casos onde relatórios em PDF foram gerados com dados misturados de múltiplos clientes, ou onde emails de notificação foram enviados para usuários do tenant errado. Background jobs rodam fora do contexto de request HTTP, então você precisa passar e validar tenant_id explicitamente.

File uploads e storage sem segregação por tenant

O quinto problema envolve arquivos e storage. Você implementa upload de arquivos mas usa um bucket ou pasta compartilhada sem separação adequada por tenant.

O desenvolvedor explica que isso acontece principalmente com serviços como S3, onde você pode configurar paths que incluem tenant_id mas esquece de validar o acesso. Um usuário mal-intencionado pode tentar acessar arquivos de outros tenants apenas mudando o path na URL.

Feng também alerta para casos onde você usa Supabase Storage ou similares e não configura corretamente as Row Level Security policies. Arquivos ficam tecnicamente separados mas acessíveis se alguém descobrir a URL.

Seeds e migrations que não respeitam multi-tenancy

O sexto erro acontece em código de manutenção: migrations de banco de dados e seeds que não consideram a estrutura multi-tenant. Você cria uma migration para adicionar dados padrão e acidentalmente insere registros sem tenant_id ou com tenant_id incorreto.

Segundo Feng, isso é especialmente problemático em sistemas que usam tenant compartilhado (shared database, shared schema). Uma migration mal escrita pode criar registros órfãos ou associar dados ao tenant errado.

O desenvolvedor recomenda sempre testar migrations em ambiente com múltiplos tenants antes de rodar em produção. Um erro aqui pode corromper dados de forma difícil de reverter.

Logs e monitoring que vazam dados entre clientes

O sétimo e último erro envolve observabilidade. Você implementa logging e monitoring mas não sanitiza os dados antes de enviar para ferramentas como Sentry, DataDog ou CloudWatch.

Feng explica que logs frequentemente contém payloads completos de requests, incluindo dados sensíveis de clientes. Se esses logs não são segregados por tenant ou se engenheiros têm acesso irrestrito, você cria um vetor de vazamento.

Além disso, dashboards de monitoring podem mostrar métricas agregadas que revelam informações sobre uso ou volume de dados de clientes específicos. O desenvolvedor recomenda implementar log sanitization e controle de acesso granular em ferramentas de observabilidade.

O que fazer agora

1. Audite todas as queries do seu código procurando por SELECT, UPDATE e DELETE sem filtro de tenant_id, use grep ou busca global na IDE
2. Revise a configuração de middlewares e verifique se todas as rotas de API estão protegidas por validação de tenant
3. Adicione tenant_id às chaves de cache em Redis ou Memcached, e teste se usuários de tenants diferentes recebem dados corretos
4. Examine workers e background jobs para garantir que recebem e validam tenant_id antes de processar qualquer dado
5. Configure segregação de storage por tenant e implemente validação de acesso em todos os endpoints de upload e download de arquivos
6. Crie um ambiente de staging com pelo menos 3 tenants fictícios e teste todas as features principais verificando isolamento de dados

Construir SaaS multi-tenant exige paranoia saudável com isolamento

Os 7 tipos de bugs documentados por Feng mostram que tenant isolation não é um problema que você resolve uma vez. É uma preocupação arquitetural que precisa estar presente em cada query, cada rota, cada job e cada arquivo.

Se você está construindo um SaaS, vale investir tempo em testes automatizados que validem isolamento de dados. Criar fixtures com múltiplos tenants e rodar testes de integração que verificam se dados nunca vazam entre clientes pode evitar problemas sérios.

Segundo reportagem publicada por Dev.to.