BOLA, BFLA e IDOR: Testes de Autorização com Burp

Resumo:

• Autenticação e autorização exercem papéis distintos, pois estar logado não garante permissão. Testar falhas exige ir além de checagens básicas de interface, focando em padrões críticos como BOLA e BFLA conforme as diretrizes do OWASP.
• A decomposição das requisições em sujeito, ação, recurso e contexto permite estruturar testes precisos e documentar evidências consistentes sobre quem tenta a operação, o que é executado, sobre qual elemento e sob quais condições.
• A categorização das vulnerabilidades abrange escalonamento vertical e BFLA, escalonamento horizontal e BOLA/IDOR, quebras cross-tenant, falhas em nível de campo e violações de workflow ou contexto para direcionar a busca em pentests.
• A construção prévia de uma matriz de permissões e o uso estratégico de contas mínimas com diferentes papéis, objetos e fronteiras de tenants permitem mapear e priorizar os riscos de segurança adequadamente.

Falhas de autorização aparecem quando uma aplicação autentica corretamente o usuário, mas permite que ele aja fora das permissões previstas. Elas podem ocorrer na fronteira entre roles (vertical), entre usuários do mesmo nível (horizontal), entre tenants, em campos específicos de um objeto ou em transições de workflow. 

A OWASP trata Broken Access Control como A01 no Top 10:2025 e dedica requisitos específicos de autorização no ASVS 5.0 V8. 

Este artigo apresenta um método orientado à matriz de acesso. A ideia não é perguntar apenas se a rota retorna 403, mas provar se um sujeito não autorizado consegue executar uma ação proibida sobre um recurso real. O fluxo recomendado combina descoberta funcional, múltiplas identidades, replays controlados, Autorize para ampliar cobertura e confirmação manual no Repeater.

Para quem está começando: a autorização envolve sujeito + ação + recurso + contexto. Isole os testes (alterando apenas o token ou apenas o ID) para identificar com precisão qual controle falhou. 

1. Por que autorização exige uma metodologia própria

Autenticação e autorização são controles diferentes. 

A autenticação responde “quem é você?”, enquanto a autorização responde “o que essa identidade pode fazer agora?”. 

Uma aplicação pode autenticar perfeitamente e ainda expor dados e funções indevidos porque a decisão de permissão está ausente, é aplicada somente na interface ou é inconsistente entre endpoints.

O OWASP WSTG orienta a testar acesso não autenticado, horizontal e vertical. Em APIs, a OWASP separa dois padrões particularmente úteis para pentesters: Broken Object Level Authorization (BOLA), quando o problema é o objeto específico acessado, e Broken Function Level Authorization (BFLA), quando a função ou endpoint deveria estar restrito a outra categoria de usuário. 

Isso significa que estar logado nunca deve ser usado como sinônimo de estar autorizado. Para cada requisição sensível, o servidor precisa decidir se aquele sujeito possui permissão para aquela operação e aquele recurso.

Figura 1: Modelo de decisão de autorização usado ao longo do artigo.

1.1 Onde novos pentesters normalmente erram

• Testar apenas uma conta de usuário comum contra uma conta admin e concluir que a cobertura está completa.
• Confiar em menus, botões ocultos ou rotas protegidas no frontend como evidência de autorização.
• Usar somente status HTTP para decidir se houve bypass.
• Encontrar um ID numérico e concluir “IDOR” sem provar que o objeto pertence a outra identidade e deveria ser negado.
• Ignorar roles intermediários, tenants, campos sensíveis e estados de workflow.
• Automatizar mutações destrutivas sem separar endpoints seguros para replay de endpoints de alto impacto.

Princípio OWASP

A Authorization Cheat Sheet recomenda privilégio mínimo, deny by default e validação de permissões em toda requisição. Para o pentester, isso vira uma hipótese testável: qualquer endpoint sensível que depende de um controle client-side, de uma rota específica ou de uma exceção de código merece atenção especial. 

2. Modelo mental: sujeito, ação, recurso e contexto

Um teste de autorização fica muito mais preciso quando você decompõe a requisição em quatro dimensões. Esse modelo também ajuda a escrever a evidência de forma objetiva.

Dimensão	Pergunta do pentester	Exemplos
Sujeito	Quem está tentando?	user_id, role, grupo, tenant, claims e service identity
Ação	O que está tentando fazer?	read, create, update, delete, approve, export e assign-role
Recurso	Sobre o quê?	user 483, invoice 7002, relatório, arquivo e tenant campo
Contexto	Quais condições influenciam?	ownership, estado do  workflow, horário, device,  região e relação entre contas

A maioria dos bypasses é uma divergência entre o que a regra de negócio esperava e o que o backend verificou. Um endpoint pode checar role, mas esquecer ownership. Outro pode checar tenant na leitura e esquecer no download. Um resolver GraphQL pode proteger a mutation, mas não um campo sensível retornado pelo objeto.

2.1 RBAC, ABAC e ReBAC

RBAC (Role-Based Access Control) é o modelo mais familiar: roles agrupam permissões. Contudo, aplicações modernas frequentemente combinam RBAC com atributos e relações. No ABAC (Attribute-Based Access Control), a decisão inclui atributos como departamento, região, classificação ou valor da transação. No ReBAC (Relationship-Based Access Control), relações como owner, member, manager-of ou collaborator determinam a permissão.

Implicação para o teste

Não limite sua matriz a “user/admin”. Em um modelo híbrido, duas pessoas com o mesmo role podem ter objetos, departamentos ou tenants diferentes. É justamente aí que o teste horizontal encontra problemas que o teste vertical não detecta.

2.2 Função, objeto e campo são camadas diferentes

Considere “GET /api/users/483”. A função “consultar usuário” pode ser legítima para um analista, mas o objeto 483 pode pertencer a uma região proibida. Mesmo quando o objeto é permitido, campos como “salary”, “riskScore” ou “internalNotes” podem exigir uma permissão adicional. ASVS 5.0 explicita controles de autorização em nível de função, dado/objeto e campo. 

3. Taxonomia de falhas

Classe	O que muda no teste	Exemplo de falha
Vertical / BFLA	identidade/role	User chama endpoint de admin
Horizontal / BOLA / IDOR	objeto/owner	User A lê invoice do User B
Cross-tenant	tenant/organização	Usuário TA acessa recurso TB
Field-level / BOPLA	propriedade	User escreve role/isAdmin ou lê campo interno
Workflow / SoD	estado/relação	Criador aprova o próprio pagamento
Contextual	atributo ambiental	Step-up exigido só na UI
Stale authorization	tempo/revogação	Role revogada continua válida em token antigo

3.1 Vertical privilege escalation / BFLA

O teste vertical pergunta se uma identidade menos privilegiada consegue executar uma função reservada. O caso clássico é um usuário comum acessar uma rota administrativa diretamente. Em APIs, também é comum a função administrativa estar misturada a rotas “normais”, portanto, não confie no nome do path para classificar o endpoint. A OWASP API5:2023 recomenda analisar a hierarquia de usuários, grupos e métodos HTTP.

Exemplo: mesma função administrativa com token de role inferior

POST /api/v1/users/483/role HTTP/1.1
Host: app.example
Authorization: Bearer <LOW_PRIV_TOKEN>
Content-Type: application/json

{"role":"admin"}

3.2 Horizontal privilege escalation / BOLA / IDOR

O teste horizontal mantém a categoria de privilégio e troca a identidade ou o objeto. Para provar BOLA, identifique dois usuários equivalentes e objetos claramente pertencentes a cada um. A OWASP API1:2023 destaca que qualquer endpoint que recebe um identificador de objeto deve validar se o sujeito pode realizar aquela ação naquele objeto.

Exemplo: User A tentando ler objeto do User B

GET /api/v1/invoices/7002 HTTP/1.1
Host: app.example
Authorization: Bearer <USER_A_TOKEN>

# invoice 7002 pertence ao User B

3.3 Cross-tenant

Em SaaS, cross-tenant costuma ser mais grave do que um IDOR entre dois usuários do mesmo tenant, porque rompe a fronteira entre clientes. Teste todas as fontes possíveis do tenant: claim no token, path, query string, body, subdomínio, headers como “X-Tenant-ID” e identificadores de objetos que indiretamente apontam para outro tenant. ASVS 5.0 V8.4.1 exige controles cross-tenant.

3.4 Field-level authorization

Nem todo objeto deve ser “tudo ou nada”. Um usuário pode estar autorizado a ver um perfil, mas não salário; pode editar “displayName”, mas não “role”, “isAdmin” ou “tenantId”. Para leitura, procure campos indevidos. Para escrita, envie propriedades que a UI não oferece e confirme o estado do objeto depois da requisição.

4.0 Planejamento e matriz de acesso

O teste de autorização eficiente começa antes do Burp. O primeiro artefato importante é uma matriz que declara quem deveria poder fazer o quê. Sem essa expectativa, uma resposta “200” é ambígua: pode ser vulnerabilidade ou comportamento legítimo.

Figura 2: Exemplo de matriz de autorização. Células de “deny” são casos de teste.

4.1 Contas mínimas

• Uma sessão não autenticada, quando aplicável.
• Dois usuários distintos com a mesma role (essencial para horizontal).
• Pelo menos uma role superior e, idealmente, roles intermediárias.
• Para multitenancy, ao menos um usuário de outro tenant.
• Contas em estados especiais quando o produto os usa: suspenso, convidado, read-only, approver, auditor, suporte.

4.2 Inventário de objetos de teste

Mantenha um inventário simples durante o assessment

USER_A owns: customer_id=1001, invoice_id=7001, report_id=9001
USER_B owns: customer_id=1002, invoice_id=7002, report_id=9002
TENANT_A: TA
TENANT_B: TB

Não confunda “ID difícil de adivinhar” com autorização. UUIDs reduzem a enumeração casual, mas não substituem a checagem de permissão. Se o UUID aparece em listagens, emails, logs, links compartilhados ou endpoints correlacionados, ele pode ser obtido e reutilizado.

4.3 Priorização por risco

Quando o tempo é limitado, comece por gestão de usuários/roles, funções administrativas, pagamentos/aprovações, exportações, dados pessoais, cross-tenant e operações de escrita/exclusão. Rotas de leitura pública e assets estáticos devem ter prioridade baixa.

5. Metodologia de execução

5.1 Descoberta funcional

1. Navegue com cada role e capture o tráfego no Proxy.
2. Marque endpoints sensíveis, objetos e identificadores.
3. Identifique métodos HTTP, endpoints alternativos, versões legadas e funções que aparecem apenas para roles maiores.
4. Revise OpenAPI, GraphQL, bundles JavaScript e chamadas mobile quando estiverem no escopo.
5. Classifique cada operação como leitura, escrita, aprovação, exclusão, exportação ou administração.

5.2 Baseline autorizado

Para cada função sensível, capture primeiro uma requisição legítima feita por uma identidade autorizada. Esse baseline prova que a operação existe e fornece um request funcional. Em seguida, mude uma dimensão por vez.

Controle experimental

No teste vertical, mantenha endpoint, objeto e payload; troque a identidade. No teste horizontal, mantenha a role e mude o objeto/owner. No cross-tenant, mantenha a função e altere a fronteira de tenant. Esse isolamento deixa a evidência muito mais forte.

5.3 Confirmar efeitos de estado

Requisições mutáveis exigem uma segunda leitura. Uma API pode devolver erro e ainda ter persistido a alteração, ou pode devolver “200” e ignorar silenciosamente um campo proibido. Depois de “POST”, “PUT”, “PATCH” ou “DELETE”, consulte o estado por uma identidade autorizada ou por outro endpoint confiável.

Figura 3: Evidência conceitual: o replay com user produz o mesmo efeito da requisição admin.

5.4 Variações que merecem cobertura

• Métodos alternativos: GET, POST, PUT, PATCH, DELETE e overrides quando usados.
• Rotas legadas e versões anteriores (“/v1”, “/v2”, “/legacy”).
• Endpoints de listagem/pesquisa e endpoints de detalhe.
• Operações bulk/batch: autorização por item.
• Downloads e jobs assíncronos.
• Identificadores em path, query, body e headers.
• Rotas acessadas por mobile ou integrações que não passam pela mesma UI.
  

6. Burp Suite + Autorize em profundidade

Autorize é uma extensão do Burp Suite para detecção automática de enforcement de autenticação e autorização. A versão publicada no BApp Store consultada para este material é 1.9.4, atualizada em 24 de fevereiro de 2026. Ela monitora o tráfego de uma identidade de maior privilégio, repete as requisições com credenciais de menor privilégio e, opcionalmente, sem autenticação, e compara as respostas. 

O papel correto do Autorize

Use a extensão para multiplicar cobertura e priorizar triage. Não use a cor “Bypassed” como prova final. O pentester ainda precisa entender a regra de negócio, confirmar o efeito e eliminar falsos positivos.

6.1 Instalação e preparação

1. No Burp Suite, abra Extensions/BApp Store e instale Autorize. Em ambientes offline, use o processo manual documentado pela PortSwigger.
2. Confirme que a nova aba Autorize aparece.
3. Prepare um token/cookie legítimo de baixo privilégio.
4. Defina o target scope antes de ligar o replay automático.
5. Separe endpoints destrutivos ou de alto custo para teste manual.

6.2 Configuração de identidade

A estratégia mais útil é navegar com uma role mais privilegiada e configurar no Autorize uma identidade real de menor privilégio. A extensão substitui/adiciona headers de autorização nas requisições repetidas. Isso preserva o request original e muda apenas a identidade.

Exemplo de credencial alternativa

Authorization: Bearer <LOW_PRIV_TOKEN>

# ou
Cookie: session=<LOW_PRIV_SESSION>

6.3 Filtros de interceptação

Filtrar é essencial. Sem filtros, assets, telemetry e chamadas irrelevantes geram ruído e consumo desnecessário. Prefira scope-only e regras específicas para “/api/”, “/admin/”, “/graphql” e rotas de negócio. Exclua imagens, fontes, scripts e healthchecks quando não agregarem valor.

Política de filtros sugerida

INCLUDE host in-scope
INCLUDE /api/ | /admin/ | /graphql
EXCLUDE \.js$|\.css$|\.png$|\.jpg$|\.svg$|\.woff$
EXCLUDE high-impact destructive endpoints from auto replay

6.4 Enforcement detectors

Autorize pode classificar enforcement com base em status, conteúdo, headers, regex e tamanho. Em aplicações que retornam “200” para erros de permissão, crie fingerprints para o corpo. Em aplicações que ocultam a existência com “404”, trate esse status conforme o padrão funcional do produto.

Exemplo de detector textual

(?i)(forbidden|not\s+authorized|unauthorized|access\s+denied|permission\s+denied)

Figura 4: Reprodução esquemática baseada na interface pública do Autorize; criada para este artigo, sem dados de cliente.

6.5 Interpretando os estados

Estado	Significado	Ação do pentester
Bypassed!	A heurística não observou o enforcement esperado.	Enviar para Repeater, comparar semanticamente e confirmar o efeito.
Enforced!	A resposta corresponde ao detector de bloqueio.	Coletar manualmente endpoints críticos. Não assumir cobertura perfeita.
Incerto / Review	A ferramenta não consegue decidir.	Ajustar detector/filtro e verificar manualmente.

6.6 Falsos positivos e negativos

• HTTP 200 com body de erro pode parecer bypass se o detector estiver pobre.
• SPAs podem devolver o mesmo HTML shell, enquanto a API de dados é protegida em outra chamada.
• 304/204, redirects, cache e conteúdo dinâmico confundem a comparação por tamanho.
• Uma resposta diferente ainda pode vazar campos sensíveis. Isso é um falso negativo se a comparação for superficial.
• Mutações assíncronas podem responder 202 e executar depois.
• Dois headers de identidade conflitantes podem fazer o replay continuar autenticado como o usuário original.

Figura 5: Fluxo de triagem recomendado para alertas do Autorize.

7. Laboratório técnico passo a passo

O objetivo deste laboratório conceitual é treinar o raciocínio. Considere três identidades: “user_A”, “user_B” e “admin”. User A e User B têm a mesma role “analyst”; cada um possui seus próprios objetos. Admin consegue gerenciar roles e exportar dados.

7.1 Caso A: BFLA: atribuição de role

1. Capture como admin uma alteração legítima de role:

POST /api/v1/users/483/role HTTP/1.1
Host: target.example
Authorization: Bearer <ADMIN_TOKEN>
Content-Type: application/json

{"role":"manager"}

2. No Repeater, troque apenas o header Authorization pelo token do User A. Não altere o path nem o body. 
3. Envie. 
4. Consulte o usuário 483. Se a role mudou, você confirmou um bypass de função; se a resposta foi “403” e o estado permaneceu igual, o controle foi aplicado.

7.2 Caso B: BOLA: invoice de outro usuário

1. Descubra um objeto de User B por um fluxo legítimo de teste. 
2. Autentique como User A. 
3. Solicite o ID de User B diretamente:

GET /api/v1/invoices/7002 HTTP/1.1
Host: target.example
Authorization: Bearer <USER_A_TOKEN>

A prova é o conteúdo do objeto indevido, não o fato de o ID ser previsível. Se o endpoint devolve apenas metadados públicos previstos pela regra de negócio, isso pode ser comportamento legítimo.

7.3 Caso C: Field-level write

PATCH /api/v1/users/me HTTP/1.1
Authorization: Bearer <USER_A_TOKEN>
Content-Type: application/json

{
  "displayName":"Analyst A",
  "role":"admin",
  "isAdmin":true,
  "tenantId":"TB"
}

Após o PATCH, faça “GET /api/v1/users/me” com uma visão confiável. Se campos privilegiados foram persistidos, há falha de autorização de propriedade. Se foram ignorados, o “200” sozinho não é achado.

7.4 Caso D: Cross-tenant

GET /api/tenants/TB/billing HTTP/1.1
Authorization: Bearer <TENANT_A_USER_TOKEN>
X-Tenant-ID: TB

Variações: altere path, header, subdomínio e IDs de objetos. O objetivo é descobrir se alguma camada confia numa fonte manipulável que não corresponde ao tenant autorizado no contexto de identidade.

8. Superfícies avançadas

8.1 GraphQL

GraphQL exige pensar em três níveis: operação, objeto e campo. Uma mutação administrativa precisa de controle function-level; um resolver que recebe “id” precisa de object-level; campos como “salary” podem exigir field-level. O fato de a resposta HTTP ser “200” é normal em GraphQL, então examine “data” e “errors”.

Teste operation-level e field-level

mutation {
  setUserRole(userId: "483", role: ADMIN) { id role }
}

query {
  user(id: "1002") { id name salary internalNotes }
}

8.2 Bulk e batch

Operações em lote devem autorizar cada elemento. Um endpoint que valida a role uma única vez e aceita uma lista de IDs pode permitir inserir objetos de outro owner/tenant no mesmo lote.

POST /api/users/bulk

{"ids":[101,102,999],"action":"disable"}

8.3 Jobs assíncronos e downloads

Teste autorização em toda a cadeia: criação do job, consulta de status e download final. É comum a criação estar protegida e o endpoint “/exports/{job_id}/download” aceitar qualquer ID válido.

POST /exports -> job_id=abc
GET /exports/abc/status
GET /exports/abc/download

8.4 Microsserviços, gateways e identidade propagada

Em arquiteturas distribuídas, o serviço downstream pode receber um token machine-to-machine muito privilegiado e perder o contexto do usuário original. ASVS V8.3.3 chama a atenção para a necessidade de decisões baseadas nas permissões do sujeito originador. Como pentester, compare comportamentos via gateway e, quando o escopo permitir, via acesso direto aos serviços, além de investigar headers de identidade que deveriam ser confiáveis apenas internamente. 

8.5 Mudança de role e autorização stale

A autorização também tem dimensão temporal. Obtenha uma sessão enquanto o usuário possui uma role privilegiada, reduza a role e repita a ação. Em tokens self-contained, a resposta depende do desenho de revogação e do TTL. Documente o requisito e não classifique automaticamente todo atraso como falha.

8.6 WebSockets

A autenticação do handshake não elimina a necessidade de autorização por mensagem. Se o protocolo permite ações como “deleteUser”, “subscribeAccount” ou “export”, repita mensagens com uma identidade que não deveria executar ou assinar aquele recurso.

9. Triagem e confirmação

A automação é melhor para responder onde olhar, enquanto a confirmação manual responde se o controle realmente falhou. Adote uma ordem de confiança para evidência.

Força	Evidência
Muito alta	Efeito de estado confirmado: registro realmente alterado, criado ou excluído.
Alta	Dado sensível proibido presente na resposta.
Média	Resposta funcional semanticamente equivalente ao baseline autorizado.
Baixa	Status HTTP, content-length ou similaridade bruta sem análise de conteúdo.

9.1 HTTP 200 não significa bypass

HTTP/1.1 200 OK

Content-Type: application/json

{"success":false,"error":"not authorized"}

Isso é um design discutível do ponto de vista semântico, mas pode estar aplicando autorização corretamente. Configure o detector com conteúdo, não só com status.

9.2 HTTP 500 não significa que a ação falhou

HTTP/1.1 500 Internal Server Error

{"error":"unexpected error"}

# Ainda assim, a transação pode ter sido persistida antes da exceção.

Sempre verifique o estado em mutações críticas.

10. Evidência, severidade e relatório

10.1 O que um achado precisa provar

• Qual era a identidade, o role e o tenant do atacante.
• Qual ação e recurso deveriam ser proibidos.
• Qual era a expectativa de negócio.
• Qual requisição demonstrou o bypass.
• Qual resposta ou efeito confirmou o acesso indevido.
• Qual é o impacto concreto para confidencialidade, integridade, disponibilidade ou fraude.

Estrutura de evidência recomendada

subject: user_A / role=analyst / tenant=TA
action: POST /api/v1/users/483/role
expected: DENY
actual: role alterada para manager
verification: GET /api/v1/users/483 -> role=manager
impact: usuário de baixo privilégio altera privilégios de outra conta

10.2 Como pensar severidade

A categoria “Broken Access Control” não determina a severidade sozinha. Um bypass que concede admin, rompe tenant, expõe PII em massa ou permite fraude tende a ser alto/crítico. Um leak de metadado pouco sensível pode ser moderado ou baixo. Considere alcance, pré-condições, obtenção de IDs e automação possível.

10.3 Higiene de evidência

Redija tokens, cookies, API keys e PII desnecessária. Preserve o mínimo de dados necessários para tornar a prova reproduzível. Em screenshots, remova segredos e informações de terceiros que não sejam essenciais.

11. Recomendações e validação de correção

Uma boa recomendação descreve o princípio arquitetural, não apenas “adicione um if”. A OWASP recomenda deny by default, least privilege e validação em toda requisição. ASVS 5.0 reforça enforcement em camada confiável, controle por função, objeto e campo, além de isolamento multi-tenant. 

• Centralizar ou padronizar a política de autorização para reduzir endpoints esquecidos.
• Aplicar enforcement no backend, próximo do recurso protegido.
• Autorizar por subject + action + resource + tenant/context.
• Buscar dados já dentro do escopo autorizado, em vez de consultar globalmente e filtrar tarde.
• Autorizar cada item em operações em lote.
• Proteger atributos usados na decisão contra manipulação pelo cliente.
• Definir como mudanças de role e revogações se propagam para sessões/tokens.
• Adicionar testes automatizados derivados da matriz de acesso.

11.1 Reteste correto

1. Repetir a PoC original com a identidade indevida.
2. Confirmar que a identidade legítima continua funcionando.
3. Testar método ou rota alternativa relacionada.
4. Testar outro objeto e role vizinha.
5. Reexecutar Autorize na área afetada para procurar regressões próximas.
6. Em multitenancy, retestar a fronteira de tenant e campos sensíveis.

12. Checklist de aprendizagem para novos pentesters

• Consigo explicar AuthN vs AuthZ sem usar os termos como sinônimos.
• Consigo montar uma matriz de roles, objetos e operações antes do teste.
• Sempre tenho dois usuários da mesma role quando preciso testar horizontalmente.
• Sei diferenciar BFLA de BOLA/IDOR.
• Confirmo mutações por estado, não apenas por resposta.
• Sei configurar uma identidade low-priv no Autorize e limitar escopo/filtros.
• Entendo por que “Bypassed” precisa de triagem manual.
• Testo tenant, campos e workflow além de endpoints.
• Evito expor tokens/PII em evidências.
• Mapeio o achado para WSTG/ASVS/API Top 10 adequado.

Exercício sugerido

Escolha uma funcionalidade administrativa e construa uma matriz com Anonymous, User A, User B e Admin. Capture uma requisição de Admin, faça replay com User A, repita horizontalmente com o objeto de User B e escreva uma evidência de uma página explicando expectativa, request, resultado e impacto.

13. Referências

OWASP Web Security Testing Guide: Bypassing Authorization Schema (WSTG-ATHZ-02). 

OWASP API Security Top 10 2023: API1 Broken Object Level Authorization. 

OWASP API Security Top 10 2023: API5 Broken Function Level Authorization. 

OWASP Application Security Verification Standard 5.0: V8 Authorization. 

OWASP Cheat Sheet Series: Authorization Cheat Sheet. 

OWASP Top 10:2025: A01 Broken Access Control. 

PortSwigger BApp Store: Autorize. 

PortSwigger/autorize: código e documentação do projeto. 

PortSwigger: Installing extensions from the BApp Store.