Uma credencial válida identifica quem entrou. A segurança do SaaS depende do que essa identidade consegue fazer, sobre quais dados e em nome de qual organização.
A fronteira precisa existir no serviço
Uma plataforma pode autenticar corretamente todos os usuários e ainda permitir que um cliente veja o contrato de outro. Em SaaS multi-tenant, o isolamento entre organizações é uma propriedade do produto. Precisa sobreviver a exportações, integrações, processamento assíncrono e suporte administrativo. Se depende da disciplina de cada tela, a fronteira está incompleta.
O OWASP API Security Top 10, edição 2023, organiza riscos de APIs e orienta sua avaliação. Não é um padrão certificável nem comprova sozinho a segurança de uma aplicação.[1]
A decisão de engenharia começa pela pergunta que interessa ao negócio: qual vínculo autoriza esta identidade a realizar esta operação sobre este recurso, neste contexto? Uma política que responde apenas qual é o perfil do usuário deixa parte essencial do problema sem definição.
Uma avaliação de API na Wardizon precisa traduzir essas relações em escopo e profundidade autorizados. O graybox oferece testes autenticados conforme o plano e o RoE; o MSP deve identificar quais credenciais e vínculos precisam ser examinados antes de descrever a cobertura ao cliente.[8][10]
Um cenário hipotético de isolamento incompleto
Considere um cenário inteiramente hipotético: um SaaS de compras atende duas empresas, Aurora e Boreal. Um colaborador da Aurora pode consultar solicitações do próprio departamento; um gestor pode aprová-las dentro de uma alçada; uma integração publica documentos autorizados.
O serviço de consulta respeita essas regras, mas a exportação recebe uma lista de documentos e inicia um trabalho em segundo plano. O trabalhador usa uma identidade técnica ampla e não preserva a autorização por documento. A tela está correta; o caminho assíncrono rompe a fronteira. O problema inclui a criação do arquivo, seu armazenamento e a autorização para baixá-lo.
Antes de corrigir um endpoint isolado, o time deve registrar o ciclo completo do recurso: criação, consulta, aprovação, exportação, retenção e exclusão. Cada etapa precisa de um responsável pela política. A mesma organização pode admitir administradores com acesso transversal, mas esse poder exige justificativa explícita e controle verificável.
Objeto, função e propriedade exigem decisões próprias
BOLA, categoria API1:2023, trata de falhas na autorização sobre objetos. Ter acesso a uma função de consulta não autoriza consultar qualquer documento. O servidor precisa avaliar a relação entre identidade, ação e objeto solicitado.[2]
BFLA, categoria API5:2023, trata do acesso indevido a funções. Consultar uma solicitação não implica poder aprová-la, alterar a alçada ou executar uma exportação administrativa. A localização da rota não determina seu privilégio.[4]
API3:2023 cobre a autorização sobre propriedades: um usuário pode ter acesso ao documento e continuar impedido de ler ou modificar determinados campos. Entrada e saída precisam respeitar essa distinção.[3]
Na implementação, essas decisões devem compor uma política compreensível. Um papel global como gestor raramente descreve sozinho o departamento, a delegação temporária e o estado da solicitação. Escreva exemplos permitidos e proibidos com o dono do processo. Uma divergência entre produto e engenharia sobre esses exemplos revela uma regra ainda indefinida.
Transformar a política em uma regra de arquitetura
A orientação de autorização da OWASP recomenda privilégio mínimo, negação por padrão e verificação das permissões em cada requisição. São fundamentos para estruturar a implementação; a política concreta continua dependendo do domínio da aplicação.[6]
Para o cenário proposto, vale estabelecer um contrato de contexto: identidade autenticada, organização validada, relação com o recurso, ação e atributos relevantes. Um identificador de organização enviado pelo cliente é uma alegação que precisa ser validada. Acesso de suporte deve ser distinguível do acesso normal, com escopo, duração e registro próprios.
Centralizar a expressão das regras reduz divergências, mas cada caminho de execução precisa aplicá-las. Verifique consultas, caches, arquivos gerados, filas e serviços internos. Revogação merece uma decisão explícita: se um usuário perder o vínculo enquanto uma exportação está em andamento, em que momento a política será reavaliada? O produto deve responder antes que o comportamento acidental do sistema se torne sua regra.
Uma operação autorizada ainda pode violar o negócio
API6:2023 chama atenção para fluxos sensíveis cujo uso excessivo ou automatizado pode prejudicar o negócio. A análise exige entender a finalidade do processo; requisições individualmente válidas podem produzir um resultado abusivo.[5]
No SaaS hipotético, a autorização para solicitar uma aprovação não deveria permitir consumir indefinidamente a capacidade operacional do cliente. Defina limites ligados ao significado da ação: solicitações por contrato, valor acumulado por período, duplicidade de processamento e quantidade de exportações simultâneas. Um limite técnico por endereço de rede pode ser útil, mas não expressa sozinho essas restrições.
Produto e segurança precisam decidir juntos quais exceções são legítimas. Processos em lote podem exigir um canal específico, cotas negociadas e supervisão. Evite transformar qualquer aumento de uso em suspeita. A restrição precisa conter um dano definido, preservar o uso contratado e oferecer tratamento operacional para situações válidas.
Testar a política com evidência de efeito
O plano de validação deve existir apenas em ambientes autorizados, com contas e dados sintéticos, escopo aprovado e critérios de interrupção. Monte uma matriz pequena e relevante de organizações, vínculos, funções, objetos e estados. Inclua acessos permitidos para demonstrar que a correção preserva o funcionamento esperado.
Para cada caso proibido, confirme tanto a resposta quanto o efeito persistido. Uma mensagem de acesso negado não comprova que nenhum arquivo foi criado, evento publicado ou alteração gravada. Nas operações assíncronas, acompanhe a execução até o resultado final. Registre também os casos em que a observação não foi suficiente para concluir.
Priorize relações de maior impacto: organizações diferentes, delegação expirada, usuário removido, mudança de alçada e privilégio de suporte. Ao corrigir uma falha, acrescente o caso ao conjunto de regressão do fluxo afetado. A seleção precisa mudar quando surgem novos consumidores, novas versões ou novas formas de compartilhar recursos.
Métricas que deixam o denominador visível
Para avaliar a autorização, acompanhe política, validação e tempo de correção. Antes de comparar períodos, fixe a população avaliada e registre suas mudanças. Uma expansão do inventário pode reduzir a cobertura medida enquanto melhora a visibilidade real.
Cobertura de política é o número de operações sensíveis com regras aprovadas e responsável definido dividido pelo total de operações sensíveis inventariadas. Cobertura de validação é o número de relações de acesso prioritárias com testes conclusivos e evidências recentes dividido pelo total dessas relações selecionadas. Um teste inconclusivo não entra como aprovado.
Acompanhe também dias desde a última validação por fluxo crítico e tempo entre a identificação de uma falha de isolamento e sua correção verificada. Separe severidade, ambiente e população exposta. Contar apenas endpoints mascara relações diferentes dentro da mesma rota; contar apenas testes incentiva muitos casos fáceis. O objetivo é reduzir incerteza sobre transações relevantes.
Levar a política de autorização para uma avaliação na Wardizon
A preparação começa com uma decisão do MSP e do cliente sobre quais fronteiras da API precisam ser examinadas: operações entre organizações, funções administrativas e propriedades sensíveis. Os alvos e a profundidade devem constar do escopo autorizado. Na Wardizon, o tipo de avaliação, o plano e o RoE delimitam a execução; testes graybox usam acesso autenticado conforme essas condições. Cabe ao MSP preparar credenciais adequadas e confirmar se representam os vínculos relevantes, preservando contas e dados de teste sempre que possível.[8][10]
Ao revisar os achados, o MSP pode usar as referências CWE e OWASP, quando aplicáveis, para conversar com engenharia sobre a classe da falha e o tratamento. A categoria precisa acompanhar a evidência: qual identidade realizou a operação, qual recurso foi alcançado e qual comportamento foi observado. O mapeamento ajuda a organizar o resultado; a conclusão sobre uma fronteira de autorização depende do que foi testado naquele fluxo.[9]
A interpretação da lógica de negócio permanece um trabalho técnico com o cliente. O MSP deve confrontar o resultado com a política esperada, identificar relações não examinadas e decidir quais verificações adicionais são necessárias. Depois da correção, a revisão precisa considerar tanto o acesso indevido quanto o funcionamento legítimo. Assim, a avaliação na Wardizon participa de uma decisão concreta sobre o produto: quais limites foram demonstrados, quais dependem de investigação e o que será exigido para encerrar a falha.
Governança da autorização exige inventário e revisão
API9:2023 destaca problemas de inventário e versões de APIs. Uma política correta perde alcance quando uma versão antiga ou um consumidor esquecido continua acessível sob regras diferentes.[7]
Por isso, o encerramento de uma correção deve incluir o inventário dos caminhos equivalentes e um plano para retirar versões sem manutenção. Aceitação temporária de risco precisa de responsável, prazo e condição de revisão. Uma demonstração bem-sucedida em homologação também não elimina diferenças de configuração ou de dados em produção.
A decisão executiva é tratar autorização como requisito de integridade do produto. Isso exige orçamento para definir políticas, revisar mudanças e verificar efeitos. Nenhum gateway, token ou relatório substitui esse trabalho. A evidência convincente identifica quem podia fazer o quê, o que foi efetivamente testado e onde ainda existe incerteza. É esse nível de precisão que sustenta confiança entre empresas que compartilham a mesma plataforma.