Entrar na plataforma não dá acesso a tudo

Uma conta válida é apenas o ponto de partida

Uma conta pode estar corretamente autenticada e receber uma fatura de outro cliente. O login funcionou. A decisão de acesso àquela fatura falhou. Esta diferença importa em áreas de cliente, dashboards internos e plataformas partilhadas por várias organizações.

O primeiro passo é descrever a relação entre a conta, o registo pedido e a ação pretendida. Uma pessoa pode pertencer a uma organização, gerir apenas um grupo atribuído ou ter acesso de consulta. Uma designação genérica de colaborador raramente descreve todos estes limites.

Estas regras devem ser revistas antes de acrescentar funções a uma aplicação existente. Exportações, pesquisas, ações em lote e downloads de documentos podem criar caminhos que o ecrã original não cobria.

Validar o pedido onde os dados são consultados

Esconder um botão ajuda a explicar a interface, mas o servidor continua a ter de decidir se aceita o pedido. Um URL copiado, um separador antigo ou uma chamada direta à API podem chegar à mesma operação sem passar pelo botão visível.

Por exemplo, a consulta de uma fatura deve combinar o identificador pedido com o âmbito autorizado da conta. A mesma regra deve abranger o download e a pré-visualização do PDF. Um identificador difícil de adivinhar pode ajudar, mas não substitui a verificação de permissões.

A orientação da OWASP sobre autorização recomenda privilégio mínimo, recusa por defeito e validação em cada pedido. Uma revisão de segurança traduz estes princípios em verificações dos perfis e registos reais da aplicação.

As alterações de permissões também têm um ciclo de vida. A remoção de um perfil deve refletir-se nas sessões ativas e operações de background conforme a política da aplicação. A equipa precisa de saber quando a alteração produz efeito e que decisões em cache precisam de ser invalidadas.

Testar os limites entre contas

Devem ser usadas contas de teste separadas, com registos e permissões diferentes. Primeiro confirma-se a ação permitida. Depois tenta-se a ação equivalente sobre um registo fora do âmbito da conta. A verificação deve incluir consulta, alteração, exportação e download.

Os testes relevantes devem ser repetidos após revogação e com uma sessão aberta antes da alteração. Perfis de consulta devem ser testados contra operações de escrita. Um pedido recusado também não deve revelar o registo numa mensagem de erro ou num ficheiro gerado.

O registo de aceitação deve indicar perfil, ação, resultado esperado e resultado observado. Um teste em desenvolvimento não comprova aceitação em produção. Deploy, comportamento real do fornecedor de identidade e percursos ainda não testados devem continuar como trabalho explícito de acompanhamento técnico.

O mesmo cuidado aplica-se a plataformas operacionais e de faturação. Documentos financeiros e dados pessoais precisam de decisões de acesso que continuem claras à medida que a plataforma cresce.