SegurançaIntermediário8 min de leitura5 seçõesanos 1990–2000, Data aproximada

Autorização (RBAC e guards)

Autorização responde *o que você pode fazer* depois de autenticado. RBAC (roles) e guards/middleware — Nest guards, Next middleware, Express — concentram a decisão perto da rota ou do caso de uso. “Tem `req.user`” não é autorização; IDOR e checagem só no front são as falhas clássicas.

Em 10 segundos

Autorização decide o que a identidade autenticada pode fazer. RBAC + guards no servidor; 401 ≠ 403; nunca confiar só no front. IDOR é falha de autorização, não de login.

Antes de ter nome

Listas de controle de acesso (ACL) em sistemas de arquivos e mainframes.

  • #seguranca
  • #rbac
  • #roles
  • #guard
  • #middleware
  • #403
Analogia

Crachá e salas

O crachá na entrada (autenticação) não abre o cofre. Cada porta tem uma lista de quem entra (autorização). Olhar pela janela se a porta “parece” trancada (UI) não tranca a porta.

01Conceito

Quem pode, de verdade

A pergunta certa é por ação e por recurso: este user pode apagar *este* post?

Guards são Chain of Responsibility na borda da rota: cada elo pode barrar.

RBAC escala bem com poucos papéis estáveis. Quando a regra depende de atributo (horário, tenant, valor), ABAC/policies evitam explosão de roles.

JWT com roles no claim acelera a checagem, mas roles revogadas no banco só somem no próximo token — para admin demovido, revalide ou use TTL curto.

02No mundo real

Como isso aparece na prática

Painel com admin e suporte

Cenário

Suporte pode ler tickets; só admin apaga usuários.

Como o padrão entra

Roles no user; requireRoles('admin') nas rotas destrutivas; auditoria append-only nas ações admin.

Trade-off: Suporte pressiona por mais poder — resista a virar tudo admin; crie permissões finas.

IDOR na API de pedidos

Cenário

GET /pedidos/123 devolvia qualquer pedido se o user estivesse logado.

Como o padrão entra

Além do guard de autenticação, filtrar where userId = req.user.id (ou admin).

Trade-off: Queries um pouco mais verbosas; testes de autorização passam a ser obrigatórios.

03Cuidado

Onde isto dá errado

  1. Guard que só checa `user != null`

    Isso é autenticação disfarçada. Qualquer conta válida passa — inclusive a do atacante recém-criada.

  2. Autorização só no frontend

    Esconder o botão não esconde o endpoint. O enforcement é no servidor.

  3. 403 e 401 trocados

    401 = autentique-se; 403 = você não pode. Clientes e caches se comportam diferente — não misture.

04Implementação

Roles + dono do recurso

// Autenticacao coloca req.user. Autorizacao decide a acao.
// Guard/middleware: role ou permissao explicita — nao so "tem user".

type Role = "user" | "editor" | "admin";

function requireRoles(...roles: Role[]) {
  return (req: any, res: any, next: any) => {
    if (!req.user) return res.status(401).json({ erro: "nao autenticado" });
    if (!roles.some((r) => req.user.roles.includes(r))) {
      return res.status(403).json({ erro: "proibido" });
    }
    next();
  };
}

// Rota sensivel: precisa ser editor OU admin.
app.delete("/posts/:id", requireRoles("editor", "admin"), apagarPost);

// IDOR: alem do role, o recurso precisa pertencer ao user (ou admin).
async function apagarPost(req: any, res: any) {
  const post = await posts.byId(req.params.id);
  if (!post) return res.status(404).end();
  const dono = post.authorId === req.user.id;
  const admin = req.user.roles.includes("admin");
  if (!dono && !admin) return res.status(403).end();
  await posts.apagar(post.id);
  res.status(204).end();
}
05Decisão

Quando usar × quando evitar

Use quando

2
  • Ações e dados que diferem por papel ou dono.
  • APIs expostas a mais de um tipo de usuário.

Evite quando

2
  • Antes de haver autenticação sólida.
  • Só no cliente, sem a mesma regra no servidor.

Testar o que ficou

3 armadilhas de Autorização (RBAC e guards) viram perguntas, com o nome do padrão escondido, misturadas com padrões parecidos.

Onde isto aparece de verdade

Você já usa isto, talvez sem saber o nome.

  • Guards do NestJSCanActivate que roda antes do handler e decide 401/403 por role ou policy.
  • middleware do Express / NextCadeia que inspeciona a sessão e barra a rota antes da lógica de negócio.
  • IAM roles / policiesA mesma ideia na nuvem: identidade autenticada + permissões explícitas por ação.

O padrão em uma linha

Sem nome de domínio, sem cerimônia. Só a ideia.

// Autenticado ≠ autorizado. Role (ou policy) na porta.
if (!req.user.roles.includes("admin")) return res.status(403).end();

O que ele cobra

1 salto a mais entre a chamada e o efeito.

  • Modelar roles/permissões e mantê-las alinhadas ao produto
  • Guards demais espalhados sem política central viram inconsistência

Não vale se: todo usuário autenticado pode tudo da mesma forma — aí autenticação basta e roles são teatro.

Costuma ser confundido com

Onde isto aparece

Continue por aqui