Um usuário pode estar autenticado e ainda assim não ter acesso a uma despesa específica. Em uma API multi-tenant, o identificador no caminho da requisição localiza o recurso. A autorização vem da relação do usuário com o tenant e das regras aplicáveis à operação.

Faça a escrita respeitar o escopo

Em uma rota de edição, confirme o vínculo ativo e a permissão do usuário. A consulta que atualiza o recurso precisa incluir tanto o ID do lançamento quanto o ID da família. Filtrar só pelo ID do lançamento depois de validar uma família indicada pelo cliente deixa espaço para cruzar dois escopos.

Para permissões que mudam durante a operação, defina se basta verificar no início ou se a escrita deve ser protegida contra uma remoção concorrente. Se a regra exigir a segunda opção, modele a operação no banco para que a escrita e a alteração de vínculo disputem o mesmo controle. O teste deve observar os resultados permitidos, com as duas operações em conexões separadas.

Onde Row-Level Security ajuda

Políticas de linha podem acrescentar uma barreira no banco. Valide com a mesma role usada em produção, pois proprietários da tabela normalmente ignoram as políticas, salvo quando são forçados a respeitá-las. Se a aplicação injeta contexto de tenant na conexão, mantenha-o restrito à transação para evitar que o pool o reutilize em outra requisição.

O teste básico usa dois tenants e repete leitura, edição e remoção com o ID do outro. Confira também o estado final do banco.

PostgreSQL Row Security Policies · Arquitetura hexagonal em Go