No seu SaaS, um cliente consegue acessar os dados de outro?

Duas empresas usam o mesmo sistema. Cada uma vê seu nome no cabeçalho, sua lista de pedidos e seus relatórios. Isso parece isolamento, mas a interface só mostra o que recebeu. A proteção precisa existir antes de o servidor devolver os dados.

Considere uma rota que busca um pedido pelo identificador. Se o servidor confirma apenas que existe uma sessão, uma pessoa autenticada pode acabar recebendo um pedido de outra empresa. O botão para abrir esse pedido nem precisa aparecer na tela.

Esse é um bom teste para fazer antes de adicionar mais relatórios ou uma busca com IA. Toda nova forma de ler dados também precisa respeitar a separação entre clientes.

Resolva a organização no servidor

O navegador pode informar qual organização a pessoa selecionou. O servidor precisa verificar a sessão, confirmar que a pessoa pertence àquela organização e autorizar a ação solicitada. Um identificador enviado no formulário não comprova acesso.

A orientação de autorização da OWASP recomenda negar por padrão e validar permissões em cada requisição. Esconder controles na interface não substitui essa verificação.

Depois de autorizar a leitura, uma consulta parametrizada pode limitar o pedido à organização verificada:

SELECT id, status, created_at
FROM orders
WHERE organization_id = $1
  AND id = $2;

Nesse exemplo, $1 vem do contexto validado no servidor. $2 é o pedido solicitado. A consulta ilustra o filtro de organização, mas não implementa sozinha as regras de acesso. Um usuário da empresa pode ter permissão para ver apenas os próprios pedidos.

Faça o mesmo raciocínio para alterações e exclusões. E verifique os relacionamentos. Um pedido da empresa A não deve aceitar uma referência a um cliente da empresa B só porque ambos os registros existem.

O banco pode reforçar a regra

O PostgreSQL oferece políticas por linha. Atenção aos papéis que ignoram essas políticas, como superusuários e BYPASSRLS. O dono da tabela normalmente também as ignora, salvo com FORCE ROW LEVEL SECURITY.

Se adotar esse recurso, teste com o papel que a aplicação usa em produção. Um teste executado como administrador pode dar uma falsa leitura da proteção. Confira também qual contexto de organização chega ao banco e como ele termina a cada operação.

Em conexões reutilizadas, nossa recomendação é passar esse contexto dentro de uma transação e limitar sua duração àquela transação. O próximo trabalho não pode herdar a organização anterior. A ausência de contexto deve impedir o acesso, e esse caso precisa de teste próprio.

Procure as saídas que não passam pela lista

Um sistema pode proteger a consulta de pedidos e vazar dados pelo relatório exportado. Inventarie os caminhos que entregam informação ao usuário.

No cache, a chave precisa distinguir a organização e o escopo de acesso relevante. Mesmo um acerto no cache deve respeitar a autorização atual. No armazenamento de arquivos, verifique o acesso antes de emitir um link temporário para download.

Em uma tarefa em segundo plano, registre a organização e a identidade responsável. Defina se o trabalho usa a permissão atual do solicitante ou uma permissão de serviço explícita. Remover uma pessoa da empresa não pode deixar a decisão de acesso ao acaso.

Uma busca com IA também entra nessa revisão. Filtre os documentos autorizados antes de enviá-los ao modelo. Pedir no prompt para não revelar dados de terceiros não corrige uma consulta que já trouxe esses dados.

Teste sempre com duas empresas

Crie dados fictícios para duas organizações. Execute a mesma operação com um usuário de cada uma e tente cruzar os identificadores. Faça isso em leituras, gravações e downloads.

Repita uma consulta depois que a outra organização tiver preenchido o cache. Teste uma tarefa criada antes da remoção de um usuário. Verifique ainda o pedido sem contexto de organização. Esses cenários pegam caminhos que um teste de login não exercita.

O resultado esperado inclui o efeito no armazenamento. Recusar a resposta depois de gravar uma alteração indevida não é proteção suficiente.

Antes de publicar a próxima função, liste quais dados ela lê e por quais caminhos eles saem. Percorra essa lista como usuário da outra empresa. É um teste mais útil que confiar no nome certo no cabeçalho.