Uma credencial válida não encerra a discussão de segurança

Uma integração entre portal, ERP e parceiros pode funcionar perfeitamente nos testes de negócio e ainda permitir acessos que ninguém pretendia autorizar. O ponto de atenção aparece quando a equipe confunde duas perguntas: quem está fazendo a chamada e o que essa identidade pode fazer com o recurso solicitado. Validar um token responde apenas à primeira parte.

Para a liderança, isso significa que a aprovação de uma API não deve se limitar a demonstrar uma transação bem-sucedida. É necessário apresentar evidências de que acessos indevidos são recusados e de que as regras continuam válidas quando mudam usuários, organizações, contratos ou responsabilidades. A segurança precisa acompanhar o significado de cada operação.

Defina autorização por recurso, ação e contexto

Uma identidade pode consultar determinados pedidos, mas não todos os pedidos existentes. A falha conhecida como autorização quebrada no nível do objeto, descrita pela OWASP, ocorre quando essa fronteira não é verificada adequadamente. Identificadores difíceis de adivinhar não substituem a decisão de acesso.

Construa uma matriz com perfis, recursos e ações: consultar, criar, alterar, aprovar e exportar. Acrescente condições relevantes, como vínculo com a organização, unidade responsável e estado do processo. O cliente da API não deve determinar sozinho a organização autorizada por meio de um parâmetro. A aplicação precisa verificar o contexto confiável e aplicar a regra no servidor, inclusive em operações de lote e buscas.

Exemplo hipotético: consultar pedidos de outra unidade

Imagine uma rede de assistência técnica com um portal para unidades parceiras. Um usuário autorizado consulta os pedidos de sua unidade. Ao trocar o identificador de um pedido na requisição, consegue visualizar informações de outra unidade. A autenticação funcionou; a separação de acesso falhou. O cenário é hipotético e não descreve uma ocorrência ou cliente da PartnerCode.

O teste de aceite deve usar identidades com vínculos diferentes e verificar tanto consultas diretas quanto listagens, anexos e exportações. A correção precisa abranger os caminhos equivalentes, não apenas o endpoint em que o problema foi percebido. Também deve considerar permissões alteradas durante a sessão e credenciais de integração que foram concedidas a um parceiro cujo contrato terminou.

Proteja campos, capacidade e rotinas de integração

Permissão para alterar um cadastro não implica permissão para modificar todos os seus campos. Defina explicitamente quais propriedades cada operação aceita e devolve. Uma mudança de responsável ou de limite de aprovação pode ter consequências diferentes de corrigir um telefone. Separe essas ações quando houver regras de autorização ou rastreabilidade distintas.

Revise o consumo de recursos por operação. Uma consulta simples e a geração de um relatório extenso têm custos diferentes. Estabeleça limites coerentes de tamanho, paginação, tempo de execução e concorrência, com tratamento previsível para quem integra. Um limite geral de requisições pode ser insuficiente se uma única chamada inicia um processamento muito caro. Avalie os impactos e ensaie o comportamento quando os limites forem atingidos.

No ciclo das credenciais, defina concessão, armazenamento, rotação e revogação, com responsáveis identificados. Evite compartilhar a mesma identidade entre parceiros: isso dificulta atribuir atividade e suspender um acesso específico. Registros operacionais devem preservar evidências úteis sem expor segredos ou copiar cargas sensíveis de forma indiscriminada.

Transforme a revisão em um processo verificável

Comece pelo inventário das APIs expostas, seus consumidores e os dados envolvidos. Priorize operações pelo impacto de leitura ou alteração indevida e pela criticidade operacional. Para cada fluxo prioritário, documente uma regra de acesso e um cenário que deve ser negado. Execute esses testes em ambiente autorizado e isolado, utilizando dados apropriados para validação.

A revisão precisa produzir evidências reproduzíveis: identidade usada, condição testada, resultado esperado e comportamento observado. Reexecute os cenários relevantes quando permissões ou fluxos mudarem. Combine os testes com uma rotina para revisar acessos de parceiros e investigar desvios. Um relatório de teste isolado perde valor se a organização não sabe quem mantém as regras atualizadas.

A PartnerCode pode apoiar o diagnóstico e a implementação desses controles nas integrações existentes ou em novas plataformas. A prioridade é tornar explícitas as fronteiras de acesso e criar critérios de validação que tecnologia e negócio consigam revisar juntos.

Referências para aprofundar

OWASP API Security Top 10 — autorização no nível do objeto: https://api-security.owasp.org/editions/2023/en/0xa1-broken-object-level-authorization/

OWASP API3 — autorização no nível das propriedades: https://api-security.owasp.org/editions/2023/en/0xa3-broken-object-property-level-authorization/

OWASP API4 — limites de consumo de recursos: https://api-security.owasp.org/editions/2023/en/0xa4-unrestricted-resource-consumption/