GitHub

Autenticação é saber "quem você é". Autorização é saber "o que você pode fazer".

Muitos desenvolvedores confundem os dois. Você logou no sistema (Autenticação ok), mas será que você pode apagar o banco de dados? Ou ver o salário do CEO? Isso é Autorização.

Gerenciar permissões é a parte mais crítica da segurança de uma aplicação. Uma falha aqui (Broken Access Control) é a vulnerabilidade número 1 no ranking da OWASP.

Neste artigo, vamos cobrir os fundamentos e as melhores práticas para implementar um sistema de permissões robusto.

Modelos de Controle de Acesso

Existem várias formas de dizer "sim" ou "não" para um usuário.

1. RBAC (Role-Based Access Control)

O mais comum. Você cria "Papéis" (Roles).

Admin: Pode tudo.
Editor: Pode criar e editar posts.
Leitor: Pode apenas ler. Você atribui o papel ao usuário (user.role = 'editor'). O código verifica: if (user.role == 'admin').
Prós: Simples de entender e implementar.
Contras: Fica rígido. E se eu quiser que um Editor específico possa apagar posts, mas só os dele?

2. ABAC (Attribute-Based Access Control)

Mais granular e poderoso. Baseia-se em atributos.

"Permitir editar SE (user.id == post.author_id) E (hora < 18:00)".
Prós: Flexibilidade infinita.
Contras: Complexidade de implementação.

3. PBAC (Policy-Based Access Control)

Define políticas em linguagem natural ou código separado.

Exemplo: AWS IAM Policies.

Princípio do Menor Privilégio (Least Privilege)

Esta é a regra de ouro: Dê ao usuário apenas a permissão mínima necessária para ele fazer o trabalho dele. Nem a mais, nem a menos.

Se um serviço só precisa ler dados, não dê permissão de escrita.
Se um desenvolvedor só precisa ver os logs, não dê acesso ao banco de dados de produção.

Isso reduz a "superfície de ataque". Se a conta desse usuário for hackeada, o estrago é limitado.

Onde Verificar a Autorização?

SEMPRE NO BACKEND. Muitos apps modernos escondem o botão "Apagar" no frontend se o usuário não for Admin. Isso é apenas UX, não é segurança. Um atacante pode chamar a API DELETE /users/1 diretamente. O Backend deve verificar a permissão em cada requisição.

IDOR (Insecure Direct Object References)

Uma falha clássica. A URL é site.com/fatura/100. Eu vejo minha fatura. Eu mudo a URL para site.com/fatura/101. Eu vejo a fatura do vizinho. Isso é IDOR. Correção: O backend deve verificar: "O usuário logado é o DONO da fatura 101?". Se não, retornar 403 Forbidden.

Conclusão

Autorização não é algo que se adiciona no final. Deve ser desenhada na arquitetura do banco de dados e da API. Use bibliotecas maduras (como CASL no JS ou Pundit) em vez de encher seu código de if/else espalhados. Segurança é controle.

Autorizacao E Permissoes - Melhores Praticas Fundamentos