Bob faz login na API do laboratório com sua própria conta válida, solicita GET /invoices/inv_100 e recebe a fatura de Alice. O atacante não roubou um token, não contornou o login nem adivinhou uma senha. Bob alterou um identificador de objeto em uma rota que o servidor aceitou sem verificar se inv_100 pertence a Bob. A questão para o defensor é, portanto, mais específica e útil do que saber se o login funciona. Para cada solicitação, a API comprova que a entidade autenticada tem permissão para realizar essa operação neste objeto?
Nosso artefato em execução é uma pequena API REST com POST /login, GET /invoices/{invoiceId}, PUT /invoices/{invoiceId} e GET /admin/audit. Alice é proprietária de inv_100, Bob é proprietário de inv_200 e um administrador pode ler registros de auditoria. Um modelo de ameaças identifica o que o atacante já controla, qual limite a solicitação atravessa, o que o atacante deseja e qual decisão do servidor deve interromper a solicitação. Aqui, Bob controla sua solicitação autenticada e o invoiceId; ele quer a fatura de Alice; a autorização deve rejeitar o acesso antes que os dados saiam do armazenamento.
A autenticação estabelece que a solicitação veio de Bob. A autorização ainda precisa decidir se Bob pode ler inv_100. Tratar essas decisões como uma única verificação gera a falha, pois uma identidade válida não diz nada sobre propriedade ou privilégio administrativo. Nosso objetivo ao longo do curso é fortalecer essa mesma API e comprovar que cada limite resiste aos testes. O mapa a seguir localiza os limites que Bob atravessa.
Este diagrama mostra por que uma solicitação pode passar pela autenticação, mas falhar na autorização ou no acesso aos dados. O identificador de objeto torna-se perigoso apenas quando a API o utiliza para recuperar um registro sem vincular esse registro à entidade autenticada (principal).
A ausência de verificação de propriedade corresponde à falha API1:2023 Broken Object Level Authorization (Autorização Quebrada em Nível de Objeto), ou BOLA, na lista OWASP API Security Top 10 de 2023. Qualquer endpoint que receba um ID de objeto controlado pelo cliente requer uma decisão de autorização para esse objeto. GET /invoices/inv_100 e PUT /invoices/inv_100 são operações distintas; portanto, cada uma exige sua própria decisão, mesmo quando ambas se referem à mesma fatura.
Os outros riscos iniciais concentram-se no mesmo caminho de solicitação. A API2:2023 Broken Authentication (Autenticação Quebrada) diz respeito a saber se a API identifica Bob corretamente. A API3:2023 Broken Object Property Level Authorization (Autorização Quebrada em Nível de Propriedade de Objeto) trata de saber se uma resposta permitida sobre a fatura expõe ou aceita campos aos quais Bob não deveria ter acesso, como um approvalLimit (limite de aprovação) interno. A API4:2023 Unrestricted Resource Consumption (Consumo Irrestrito de Recursos) refere-se ao envio, por parte de Bob, de solicitações custosas com frequência suficiente para esgotar a capacidade ou acionar processos subsequentes pagos. A API5:2023 Broken Function Level Authorization (Autorização Quebrada em Nível de Função) diz respeito ao acesso de Bob ao endpoint GET /admin/audit, apesar de ele não possuir permissão administrativa.
Cada categoria altera uma parte diferente da solicitação, mas todas testam se o servidor impõe um limite de segurança em vez de confiar cegamente na entrada do cliente, apenas em um token ou no nome do endpoint. A tabela avalia a alteração feita pelo atacante, o resultado protegido e as evidências necessárias para os defensores.