Controle de acesso e autorização

É por isso que precisamos garantir:

Princípios de autorização

• Mínimo privilégio: conceder apenas as permissões estritamente necessárias.
• Negação por padrão: se não houver uma permissão explícita, o acesso deve ser negado.
• Verificação no backend: as verificações devem ser feitas sempre do lado do servidor, nunca confiar em validações do frontend. Devem ser realizadas mediante fontes confiáveis como a sessão, e não a partir de parâmetros facilmente manipuláveis por um usuário.
• Verificação em cada solicitação: deve-se validar em cada operação as permissões antes de executá-la.

Vejamos um exemplo de cada princípio:

Mínimo privilégio:

❌ INCORRETO:

Todos os operadores têm acesso de administrador
"Por precaução, caso precisem de algo"

Problema: Um operador comprometido = acesso total

✅ CORRETO:

Função "Operador de pedidos":
   ✅ Ver pedidos
   ✅ Atualizar status de envio
   ❌ Modificar preços
   ❌ Excluir publicações
   ❌ Gerenciar usuários

Só tem acesso ao que precisa para o seu trabalho.

Negação por padrão:

❌ INCORRETO:

if (user.role == "blocked") {
    denyAccess();
}
// Se não está bloqueado, tem acesso

Problema: Novas funções têm acesso por padrão

✅ CORRETO:

if (user.hasPermission("view_orders")) {
    allowAccess();
} else {
    denyAccess();  // Por padrão, negar
}

Se não tem permissão explícita, não tem acesso.

Verificação no backend:

❌ INCORRETO:

// Frontend (JavaScript)
if (user.role === "admin") {
    showAdminButton();
}

// Backend: Não verifica nada, confia no frontend

Problema: Atacante pode modificar o JavaScript ou chamar
diretamente a API sem passar pelo frontend.

✅ CORRETO:

// Frontend (JavaScript)
if (user.role === "admin") {
    showAdminButton();
}

// Backend (em cada request)
if (!user.hasPermission("admin_action")) {
    return error(403, "Não autorizado");
}

// Processar apenas se tiver permissão

Verificação em cada solicitação:

❌ INCORRETO:

Usuário faz login → Verifica-se uma vez → Tem acesso a tudo

Problema: Se as permissões mudarem após o login,
não é refletido

✅ CORRETO:

Cada solicitação:
   1. Verificar que a sessão é válida
   2. Verificar que o usuário tem permissão para
      esta ação
   3. Verificar que o usuário tem acesso a este seller
   4. Somente então, processar a solicitação

Segregação por seller

• Estabelecer um esquema de funções e permissões que permita atribuir sellers de forma explícita, de modo que cada usuário só possa gerenciar os sellers que lhe foram permitidos.
• Validar em cada operação, antes de exibir ou modificar dados, que a conta em questão tem acesso a esse seller.
• Validar, na medida do possível, poder responder às perguntas: "Quem fez o quê, de onde, quando e com qual resultado?" com os logs disponíveis em cada funcionalidade da aplicação.

Apoiemo-nos no exemplo a seguir para maior clareza:

❌ SEM SEGREGAÇÃO:

SEU SISTEMA
+-------------------------------------------+
|                                           |
|  João (op.) --> Seller A    OK            |
|             --> Seller B    [X] sem perm. |
|             --> Seller C    [X] sem perm. |
|                                           |
+-------------------------------------------+
Problema: João acessa sellers não atribuídos

✅ COM SEGREGAÇÃO:

SEU SISTEMA
+-------------------------------------------+
|                                           |
|  João (op.) --> [Seller A] --> PERMITIDO  |
|      |                                    |
|      +--[X]--> [Seller B] --> NEGADO      |
|      |                                    |
|      +--[X]--> [Seller C] --> NEGADO      |
|                                           |
+-------------------------------------------+
Acessa apenas os sellers que tem atribuídos

Gestão de permissões

• Revisão periódica: auditar as permissões e realizar uma re-certificação de acessos.
• Revogação imediata: ao desvincular um colaborador, revogar os acessos imediatamente.
• Registro de alterações: documentar quem concedeu/revogou qual permissão e quando.
• Separação de funções: quem aprova permissões não deve ser quem as solicita.

Como podemos verificar que seguimos os princípios de autorização?

1. Crie 2 contas de usuário de teste.
2. Atribua o seller A ao usuário 1.
3. Atribua o seller B ao usuário 2.
4. Inicie sessão como usuário 1.
5. Tente acessar dados do seller B.

Resultado	Significa
Você consegue ver os dados do seller B	❌ Seu esquema de autorização falhou, você deve ajustá-lo até que não permita isso
Você consegue realizar ações com uma função que não tem permissões específicas para fazê-las	❌ Seu esquema de autorização falhou, você deve ajustá-lo até que não permita isso
Erro 403 / 401 "Acesso negado"	✅ Seu esquema de autorização está funcionando
Erro 404 "Não encontrado"	✅ Seu esquema de autorização está funcionando e com tratamento de erros que oculta a existência do recurso

Prevenção de acesso a recursos não autorizados (IDOR)

Exemplo: se a aplicação exibe pedidos em /orders/12345, um atacante poderia tentar /orders/123456 para ver pedidos de outro seller.

❌ VULNERÁVEL A IDOR:

# ❌ VULNERABLE A IDOR:

@app.get("/orders/{order_id}")
def get_order(order_id: int):
    order = database.get_order(order_id)
    return order  # Não verifica se o usuário tem acesso

# Problema: Qualquer pessoa pode ver qualquer pedido alterando o ID

O ideal seria que sempre se validasse que o usuário que faz a solicitação realmente tenha permissões para fazê-la:

✅ PROTEGIDO CONTRA IDOR:

# ✅ PROTEGIDO CONTRA IDOR:

@app.get("/orders/{order_id}")
def get_order(order_id: int, current_user: User):
    order = database.get_order(order_id)

    # Verificar que o pedido pertence ao seller do usuário
    if order.seller_id not in current_user.allowed_sellers:
        raise HTTPException(403, "Você não tem acesso a este pedido")
    return order

É importante considerar os seguintes mecanismos de proteção contra esse tipo de falha:

• Sempre validar a propriedade: antes de exibir ou modificar um recurso, verificar que pertence ao usuário/seller. No caso de funcionários ou colaboradores, garantir que eles tenham as permissões necessárias para consultar recursos do seller correspondente.
• Validação no servidor: a validação deve estar sempre do lado do backend e não do cliente (frontend).
• Validar cada endpoint: não assumir que, se passou pela autenticação, já tem autorização.
• Usar o contexto de sessão: obter o seller_id ao resolver o token de sessão e nunca de parâmetros da solicitação.

Recursos a proteger:

• Pedidos de compra e informações das vendas.
• Publicações.
• Perguntas.
• Mensagens.
• Envios.
• Pagamentos.
• Qualquer informação ou outra função não pública exclusiva do vendedor.

PARA CADA TIPO DE RECURSO, TESTE:

  ( 1 ) Inicie sessão como Usuário A
    |
    v
  ( 2 ) Acesse um recurso próprio (ex: /orders/123)
    |
    v
  ( 3 ) Copie a URL
    |
    v
  ( 4 ) Inicie sessão como Usuário B (em outro navegador)
    |
    v
  ( 5 ) Cole a URL do recurso do Usuário A

Referências

• OWASP Authorization Cheat Sheet: guia completo de controle de acesso e autorização.
• OWASP IDOR Prevention Cheat Sheet: guia específico para prevenir IDOR.
• OWASP Top 10 - A01:2021 Broken Access Control: problemas de controle de acesso mais comuns.
• CWE-284: Improper Access Control: categoria principal de problemas de controle de acesso.
• MELI - Autenticação e Autorização: documentação oficial do OAuth no MercadoLibre.

Glossário

Termo	Significado
Autorização	Verificar O QUE um usuário já autenticado pode fazer (permissões, funções, recursos)
RBAC	Role-Based Access Control - Controle de acesso baseado em funções (admin, operador, viewer, etc.)
ABAC	Attribute-Based Access Control - Controle de acesso baseado em atributos (departamento, localização, horário, etc.)
Princípio do mínimo privilégio	Dar a cada usuário apenas as permissões estritamente necessárias para sua função
Escalada de privilégios	Ataque onde um usuário obtém permissões que não lhe pertencem
Escalada horizontal	Acessar recursos de outro usuário do mesmo nível (ex: ver pedidos de outro seller)
Escalada vertical	Obter permissões de uma função superior (ex: usuário comum age como admin)
Object-level authorization	Verificar permissões no nível de cada objeto/recurso individual, não apenas no nível de endpoint
Bypass de autorização	Contornar controles de acesso para realizar ações não permitidas
Middleware de autorização	Camada de código que verifica permissões antes de executar a lógica do endpoint
Auditoria de acesso	Registrar quem acessou qual recurso e quando, para detectar acessos indevidos

Próximo: Segurança de aplicações.