Rodrigo Brito

Uma visão prática sobre segurança em APIs corporativas

Em muitas aplicações corporativas, a autenticação parece estar corretamente implementada. O usuário acessa pelo SSO, o token JWT é emitido, o MFA está habilitado, o gateway valida a requisição e o backend responde sem erro aparente. À primeira vista, tudo indica que o fluxo de segurança está funcionando.

Mas existe uma pergunta que nem sempre é respondida com a mesma clareza: depois que o usuário foi autenticado, ele está realmente autorizado a acessar aquele recurso, executar aquela ação ou visualizar aquele dado específico?

Essa foi a reflexão central da palestra que apresentei no RioCyberSec Happy Hour #2: em APIs corporativas, o login funcionando não significa, necessariamente, que a aplicação está segura. Autenticar bem o usuário é importante, mas não garante que ele esteja autorizado a interagir com todos os recursos expostos pela API.

A decisão de acesso não está apenas no token. Ela precisa estar refletida no código, na arquitetura e nas regras de negócio da aplicação.

Autenticação e autorização não são a mesma coisa

Uma das confusões mais comuns em ambientes corporativos é tratar autenticação e autorização como se fossem etapas equivalentes.

• A autenticação responde a uma pergunta: quem é você?
• A autorização responde a outra: o que você pode fazer, sobre qual recurso e em qual contexto?

Um token JWT válido pode comprovar identidade, expiração, assinatura e alguns atributos do usuário. Ele pode indicar que aquele usuário passou pelo fluxo correto de login. Pode carregar claims, grupos, roles ou informações vindas de um provedor de identidade, como o Entra ID. Mas o token, sozinho, não prova que aquele usuário pode acessar determinado contrato, documento, cliente, matrícula, unidade, área, tenant ou processo interno. Essa decisão precisa ser tomada pela aplicação, considerando a regra de negócio. É nesse ponto que muitas APIs corporativas falham.

O backend valida que existe um token válido, mas não valida se o recurso solicitado pertence ao contexto daquele usuário. O resultado é uma API que parece segura do ponto de vista de autenticação, mas frágil no controle real de acesso.

APIs corporativas carregam regra de negócio

Uma API corporativa raramente expõe apenas dados genéricos. Ela costuma refletir processos internos, integrações entre sistemas, permissões funcionais, hierarquias, unidades organizacionais, contratos, documentos e fluxos de aprovação. Por isso, testar uma API corporativa exige mais do que verificar se o endpoint responde 200, se o token é aceito ou se os headers estão corretamente configurados.

• A pergunta mais importante não é apenas: “O endpoint respondeu?”
• A pergunta correta é: “Esse usuário, com esse perfil, nesse contexto, deveria receber essa resposta?”

Um 200 OK pode ser tecnicamente correto e, ao mesmo tempo, representar uma falha de segurança. A resposta pode estar bem formada, o JSON pode estar íntegro, a sessão pode estar válida, mas o dado pode ter sido entregue para quem não deveria recebê-lo.

Esse é um ponto fundamental: em APIs corporativas, autorização é regra de negócio implementada em código.

Quando o problema não é o login

Um exemplo simples ajuda a ilustrar.

Se a API retorna os documentos do cliente 1025, o problema não está no login. O token continua válido. A sessão continua válida. O endpoint continua funcionando. A falha está no vínculo que nunca foi verificado.

A aplicação não validou se aquele usuário poderia acessar aquele cliente específico. Ela apenas aceitou um identificador enviado na URL e retornou o recurso correspondente.

Esse é o padrão clássico de Broken Object Level Authorization, frequentemente associado a IDOR em aplicações web. Em termos práticos, o usuário autenticado consegue acessar objetos de terceiros manipulando identificadores, parâmetros ou referências diretas a recursos. O ponto central não é o nome da vulnerabilidade. O ponto central é que a API validou identidade, mas não validou pertencimento, contexto e autorização sobre o objeto.

Autorização funcional não substitui autorização por recurso

Outro erro comum é confundir permissão funcional com permissão sobre dados.

Uma permissão como documents:read pode indicar que o usuário tem acesso ao módulo de documentos. Mas ela não responde quais documentos esse usuário pode visualizar.

Um perfil pode permitir acesso a uma funcionalidade, mas isso não significa que o usuário pode acessar todos os registros daquela funcionalidade. Um colaborador pode ter permissão para consultar documentos, mas apenas documentos da sua unidade, da sua carteira, do seu contrato, do seu tenant ou do seu escopo de atuação. Autorização funcional e autorização por recurso precisam andar juntas.

• A primeira responde se o usuário pode usar determinada função.
• A segunda responde se ele pode usar aquela função sobre aquele recurso específico.

Quando uma dessas camadas falta, surgem falhas como BOLA, BFLA e BOPLA.

• BOLA aparece quando o usuário acessa objetos que não pertencem ao seu contexto.
• BFLA ocorre quando funções privilegiadas, como endpoints administrativos, podem ser chamadas por usuários comuns porque a checagem foi feita apenas na interface.
• BOPLA aparece quando a API expõe ou aceita propriedades que não deveriam estar disponíveis para aquele usuário, como campos sensíveis retornados em excesso ou atributos alteráveis indevidamente.

O campo que não deveria estar ali

Um caso bastante comum em APIs é o mass assignment. Imagine um endpoint para atualização de perfil:

PATCH /api/usuarios/482/perfil Authorization: Bearer <token> { "nome": "Maria Silva" }

Esse seria o comportamento esperado: o usuário atualiza um campo permitido. Agora imagine que o cliente envie um campo extra:

PATCH /api/usuarios/482/perfil Authorization: Bearer <token> { "nome": "Maria Silva", "role": "admin" }

Se o backend aceitar esse campo e gravar diretamente no modelo de dados, o problema não foi o usuário ter enviado um JSON malicioso. O problema foi a aplicação aceitar de volta um campo que nunca deveria ser controlado pelo cliente.

Esse tipo de falha mostra que a API não deve confiar no corpo da requisição apenas porque ele veio de uma sessão autenticada. Campos sensíveis precisam ser protegidos por allow-list, regras de domínio e validações explícitas. O usuário pode estar autenticado e ainda assim não deve conseguir alterar sua própria role, seu tenant, seu nível de aprovação ou qualquer outro atributo que tenha impacto de autorização.

Claims JWT não são permissão em tempo real

Outro ponto importante é o uso de claims dentro de tokens JWT. Um claim é uma alegação assinada em determinado momento, geralmente no login ou na emissão do token. Ele pode informar papel, grupo, tenant, unidade ou outros atributos do usuário. Isso é útil, mas pode ser perigoso quando a aplicação trata essas informações como autorização final e imutável. Se uma role é removida no painel administrativo, mas a API continua confiando no valor antigo presente em um token ainda válido, a permissão revogada pode continuar funcionando até a expiração do token. Isso cria uma diferença entre o estado real da autorização e o estado congelado no token.

Claims de identidade podem ser úteis para identificar o usuário e reduzir consultas desnecessárias. Mas claims sensíveis de autorização, como papel, tenant, unidade ou escopo privilegiado, precisam ser tratados com mais cuidado. Dependendo do risco da operação, é necessário reconfirmar permissões contra a fonte de verdade, usar tokens de vida curta, aplicar introspecção ou manter uma estratégia clara de revogação.

O erro está em transformar o token em autoridade absoluta. O token ajuda a responder quem é o usuário. A aplicação ainda precisa decidir o que ele pode fazer.

Entra ID autentica. Quem autoriza é a API

Esse problema também aparece em ambientes que utilizam provedores corporativos de identidade, como o Entra ID. A integração com SSO é uma prática importante. Ela melhora governança de identidade, centraliza autenticação, permite MFA e reduz riscos associados a credenciais locais. Mas ela não elimina a necessidade de autorização na aplicação. O provedor de identidade resolve uma parte do problema: quem é o usuário. A API precisa resolver outra: o que esse usuário pode acessar dentro do sistema.

Em aplicações internas, é comum ver grupos, app roles ou claims vindos do provedor de identidade sendo tratados como decisão final de acesso. Em alguns casos, isso funciona para permissões amplas. Mas, para regras granulares de negócio, normalmente não é suficiente. O Entra ID pode dizer que o usuário pertence a determinado grupo. Mas dificilmente ele sabe, sozinho, se aquele usuário pode acessar um contrato específico, um documento interno, uma matrícula, uma unidade operacional ou um registro vinculado a outro contexto de negócio. Essa decisão continua sendo responsabilidade da aplicação. SSO corporativo não substitui modelagem de autorização.

O frontend não é fronteira de segurança

Outro padrão recorrente é confiar que a interface do usuário impedirá o abuso. A aplicação oculta botões, remove opções do menu, limita filtros ou controla visualmente o que cada perfil pode acessar. Isso melhora a experiência e reduz erros, mas não pode ser tratado como controle de segurança suficiente. Um atacante, ou até um usuário interno curioso, não precisa usar a interface da forma prevista. Ele pode interceptar chamadas, alterar parâmetros, repetir requisições, modificar payloads e chamar endpoints diretamente. Se a API não validar a requisição de forma independente, o frontend vira apenas uma camada estética. O backend precisa assumir que qualquer parâmetro pode ser manipulado, qualquer identificador pode ser alterado e qualquer campo enviado pelo cliente pode ser malicioso ou indevido. A regra é simples: a decisão de autorização precisa ocorrer onde a ação realmente acontece. E, em APIs, isso significa o backend.

Testes negativos são essenciais

Autorização não se valida apenas testando o fluxo feliz. É preciso testar o que o usuário não deveria conseguir fazer. Em BOLA, por exemplo, o teste ideal envolve pelo menos dois usuários. Com o usuário A, cria-se ou identifica-se um recurso. Com o usuário B, tenta-se acessar esse mesmo recurso diretamente pelo ID ou referência. Se o usuário B recebe o dado do usuário A, a autorização falhou. Esse raciocínio deve ser repetido em diferentes métodos e operações:

• GET para leitura.
• PUT ou PATCH para alteração.
• DELETE para exclusão.
• POST para criação com campos indevidos.

Também é importante testar endpoints administrativos com tokens comuns, parâmetros de contexto como tenant_id ou unidade_id, IDs sequenciais, UUIDs previsíveis, campos extras no corpo da requisição e diferenças entre respostas 200, 403 e 404 que possam indicar a existência de recursos.

Esse tipo de teste exige entendimento de contexto. Ferramentas automatizadas ajudam, mas não substituem a análise de negócio.

O papel do pentest interno

No contexto de pentest interno, existe uma oportunidade que vai além da evidência. Encontrar a falha é importante. Mas, para a organização, o maior valor está em transformar o achado técnico em melhoria real de engenharia. Isso significa explicar o impacto no negócio, apontar a causa provável, indicar o ponto de correção, propor uma recomendação aplicável, sugerir teste de regressão e, quando possível, ajudar a transformar a correção em padrão reutilizável.

Às vezes, a correção não é apenas adicionar uma validação local em um endpoint específico. O problema pode estar no desenho da aplicação. Pode faltar uma camada comum de autorização, uma policy, um middleware, uma regra de domínio ou uma consulta filtrada pelo contexto do usuário. Quando o pentest interno atua próximo aos times de desenvolvimento, o relatório deixa de ser apenas uma lista de vulnerabilidades. Ele passa a ser insumo de engenharia. Esse é um ponto que considero essencial: o objetivo não é provar que o desenvolvedor errou. Muitas vezes, o requisito de segurança simplesmente não chegou claro até o código. O desenvolvedor recebeu a tarefa de listar documentos, atualizar perfis ou consultar contratos. Mas talvez ninguém tenha explicitado que aquele dado só poderia ser acessado por determinadas unidades, perfis, vínculos ou contextos. Segurança precisa ajudar a traduzir risco em requisito técnico.

Saber programar muda a recomendação

Uma recomendação genérica como “implementar controle de acesso no backend” pode estar correta, mas raramente é suficiente. Ela aponta a direção, mas não ajuda muito quem precisa corrigir. Uma recomendação melhor seria: “Validar se o recurso solicitado pertence ao contexto do usuário autenticado, considerando vínculo, perfil, unidade, contrato ou tenant, antes de retornar, alterar ou excluir dados.” Essa diferença parece pequena, mas muda bastante o diálogo com o desenvolvimento. Quem entende programação consegue discutir onde a validação pode acontecer: controller, middleware, service, policy, regra de domínio ou query. Também consegue diferenciar uma falha pontual de um problema arquitetural.

Esse exemplo não é uma receita universal. Cada aplicação terá sua arquitetura, seu modelo de dados e suas regras. Mas ele ilustra uma mudança importante: a autorização precisa participar da forma como o recurso é localizado e manipulado. Não basta validar que o usuário está logado. É preciso garantir que a consulta, a alteração ou a exclusão aconteça dentro do escopo autorizado.

Segurança e desenvolvimento precisam falar a mesma língua

A segurança de APIs corporativas não evolui apenas com ferramentas, relatórios ou checklists. Ela evolui quando segurança entende melhor o funcionamento da aplicação, e quando desenvolvimento recebe requisitos de segurança mais claros, objetivos e implementáveis. Essa aproximação é especialmente importante em ambientes internos, onde as aplicações refletem processos específicos da organização. Muitas regras não estão evidentes para quem olha apenas de fora. É preciso entender fluxo, dado, vínculo, perfil, unidade e impacto.

O pentest interno tem uma posição privilegiada nesse sentido. Ele consegue observar padrões recorrentes, apoiar correções, identificar falhas sistêmicas e contribuir para que a organização amadureça sua forma de construir software seguro.

No fim, a mensagem principal é simples: Autorização é regra de negócio implementada em código. SSO, MFA, JWT, WAF e gateways são controles importantes. Mas nenhum deles substitui a validação por recurso, no contexto correto, no backend. Se o usuário está autenticado, a conversa só começou.

A pergunta que realmente protege a API é: Ele está autorizado a fazer isso, neste recurso, neste contexto?