Como Adicionar Controlo de Acesso Baseado em Funções (RBAC) à Sua App

Para adicionar controlo de acesso baseado em funções, atribua a cada utilizador uma ou mais funções (por exemplo administrador, editor, leitor), defina que ações cada função pode executar, e verifique essas permissões no servidor em cada pedido — não apenas escondendo botões. Verifique também se o registo a que se acede pertence à conta ou à equipa do utilizador. Comece com algumas funções fixas na sua base de dados, e teste tentando aceder diretamente aos dados de outro utilizador.

Autenticação vs. autorização

Duas palavras que se confundem facilmente:

• Autenticação é quem é você? — o login. Veja como adicionar login à sua app.
• Autorização é o que tem permissão para fazer? — que páginas, registos e ações um utilizador com sessão iniciada pode alcançar.

O RBAC é a forma mais comum de fazer autorização. É importante: a partir de setembro de 2026, o Broken Access Control está em primeiro lugar no OWASP Top 10:2025, a lista amplamente usada dos riscos de segurança mais graves em aplicações web. As falhas típicas são utilizadores a ler registos de outros utilizadores ao alterar um ID no URL, ou utilizadores comuns a chamar rotas da API reservadas a administradores.

Escolher um modelo

Na prática, a maioria das apps combina duas coisas: funções para o tipo de ações que alguém pode executar, e propriedade para os registos sobre os quais as pode executar. «Os editores podem editar publicações» é uma regra de função; «…publicações do seu próprio espaço de trabalho» é uma regra de propriedade. Precisa das duas.

Comece mais simples do que imagina. Administrador, membro e leitor cobrem um número surpreendente de apps. É mais fácil dividir uma função mais tarde do que desembaraçar dez funções que ninguém percebe.

Desenhar as funções antes de escrever código

Escreva primeiro uma tabela de permissões em linguagem simples. Serve como especificação para a IA e como plano de testes:

Decida também os casos limite: o último proprietário pode sair? Um administrador pode remover o proprietário? O que vê um utilizador removido?

Passo a passo

1. Tenha primeiro um login a funcionar

O RBAC assenta sobre a autenticação. O servidor tem de saber de forma fiável quem está a fazer cada pedido, a partir de uma sessão ou de um token verificado — nunca a partir de um ID de utilizador que o navegador envia no corpo do pedido.

2. Guardar as funções na base de dados

Para uma app de uma só equipa, uma coluna role nos utilizadores é suficiente. Para equipas, use uma tabela de membros:

create table memberships (
  user_id uuid references users(id),
  organization_id uuid references organizations(id),
  role text not null check (role in ('owner','admin','member','viewer')),
  primary key (user_id, organization_id)
);

Nunca deixe os utilizadores definirem a própria função através de uma atualização normal do perfil. As alterações de função passam por um endpoint dedicado, com verificação de permissões.

3. Verificar as permissões no servidor, num só lugar

Escreva uma função auxiliar — algo como can(user, 'projects.delete', project) — e chame-a em cada rota da API, ação do servidor e tarefa em segundo plano que leia ou altere dados. Uma função central é mais fácil de rever e testar do que verificações espalhadas pelo código. Negue por omissão: se nenhuma regra permitir uma ação, ela é recusada.

4. Limitar todas as consultas

Cada consulta a dados da equipa deve incluir a equipa: where organization_id = :currentOrg, e não apenas where id = :id. É isto que impede alguém de mudar /projects/123 para /projects/124 e ver o projeto de outra empresa. Devolva «não encontrado» em vez de «proibido» para registos de outras equipas, para não revelar que existem.

5. Acrescentar proteção ao nível da base de dados onde conta

A segurança ao nível das linhas (RLS) do Postgres permite que a base de dados imponha que linhas cada utilizador pode ver. É essencial se o navegador falar diretamente com a base de dados (como acontece com alguns backends alojados), e uma segunda camada útil para tabelas sensíveis nos restantes casos.

6. Refletir as funções na interface

Agora esconda ou desative o que os utilizadores não podem fazer, para que a app não seja confusa. Isto serve apenas para a utilização; quem protege são as verificações do servidor.

7. Registar ações sensíveis

Registe quem alterou funções, eliminou dados ou exportou registos, e quando. Um registo de auditoria ajuda a responder a pedidos de apoio e a incidentes.

8. Teste como um atacante

Entre como cada função e experimente cada ação da tabela de permissões. Depois tente as coisas que não deviam funcionar: chamar rotas de administração como leitor, alterar IDs em URLs e pedidos, remover-se a si próprio como último proprietário. Vale a pena escrever testes automáticos para a tabela de permissões quando as regras estiverem assentes.

Prompts que funcionam

Adicione controlo de acesso baseado em funções. Funções por organização: proprietário, administrador, membro, leitor, guardadas numa tabela de memberships. As permissões estão nesta tabela: [cole a sua tabela]. Crie uma única função auxiliar no servidor can(user, action, resource), com negação por omissão, e use-a em todas as rotas da API. Limite cada consulta por organization_id. Esconda na interface as ações que o utilizador não pode executar, mas nunca confie nisso para a segurança.

Reveja todas as rotas da API e funções do servidor desta app. Para cada uma, liste que dados lê ou altera, se verifica que o utilizador tem sessão iniciada, se verifica a sua função e se limita a consulta à sua organização. Corrija as que não tenham verificação e mostre-me a lista.

Adicione uma página /admin, apenas para administradores, onde o proprietário possa alterar as funções dos membros. Impeça a remoção ou o rebaixamento do último proprietário, registe cada alteração de função com quem a fez e quando, e garanta que o endpoint de alteração de funções recusa qualquer pessoa que não seja proprietária.

Erros comuns

• Verificar funções apenas no frontend. A API continua aberta a qualquer pessoa que a chame.
• Confiar em IDs vindos do cliente — um userId ou role no corpo do pedido em vez da sessão.
• Consultas sem limite que vão buscar por ID de registo apenas.
• Funções verificadas nas páginas mas não nas rotas da API, nas exportações, nos downloads de ficheiros ou nos webhooks.
• Administrador por endereço de email fixo no código (if email === 'eu@...'), fácil de esquecer e difícil de mudar.
• Funções demais cedo demais, que ninguém consegue explicar seis meses depois.
• Sessões desatualizadas: um utilizador rebaixado mantém direitos de administrador até terminar sessão. Verifique as funções na base de dados, ou atualize-as, em ações sensíveis.

Lista de verificação do RBAC

• Tabela de permissões escrita em linguagem simples, com os casos limite decididos
• O servidor conhece o utilizador pela sessão, nunca pelos dados do pedido
• Funções guardadas na base de dados; os utilizadores não as podem alterar a si próprios
• Uma única verificação de permissões central, com negação por omissão, usada em todas as rotas
• Cada consulta limitada à organização ou propriedade do utilizador
• Segurança ao nível das linhas onde o navegador consegue chegar à base de dados
• A interface esconde o que os utilizadores não podem fazer (apenas para a utilização)
• Ações sensíveis registadas
• Cada função testada, incluindo chamadas diretas à API e IDs alterados

O controlo de acesso é um item de uma lista mais longa; a lista de verificação de segurança para apps criadas com IA cobre o resto. Se estiver a criar uma ferramenta para a sua própria equipa, como criar uma ferramenta interna mostra onde encaixam as funções.

RBAC na Mythex

A Mythex não oferece um sistema de login ou de funções integrado para os utilizadores da sua app. Escolhe uma biblioteca ou um fornecedor de autenticação e descreve as funções, e o agente liga-as ao seu código e à base de dados Postgres do projeto (adicionar login à sua app). As funções de espaço de trabalho da própria Mythex, como Proprietário e Membro, controlam quem pode editar os seus projetos Mythex, não quem pode usar a app que publica. Use o modo Plan para acordar a tabela de permissões antes de construir, depois use o prompt de revisão acima e teste cada função em Preview antes de publicar. Os prompts de segurança da documentação são um bom seguimento.

Perguntas