Como testar permissões antes de abrir uma aplicação a utilizadores

Define quem pode fazer o quê antes de testar

Uma aplicação precisa de regras claras sobre pessoas, objetos e ações. Começa por escrever essas regras em linguagem simples, usando o percurso real do utilizador. Se a equipa ainda não decidiu quem pode editar ou aprovar determinado registo, um teste técnico não consegue determinar sozinho qual deveria ser o comportamento correto.

Vamos trabalhar com um portal fictício de pedidos de revisão. Cada cliente vê os seus pedidos e pode alterar um rascunho. Um revisor atribuído pode comentar. Só o coordenador pode marcar a revisão como concluída. Estes papéis servem para construir o exemplo, não são regras universais para qualquer aplicação.

A pergunta “o cliente tem acesso?” é insuficiente. Acesso a quê, em que estado e para fazer o quê? Um cliente pode ler um pedido submetido sem poder alterar o seu conteúdo. Um revisor pode comentar um pedido atribuído sem poder abrir os pedidos de outros clientes.

Escreve cada regra com esses elementos. Por exemplo: “O cliente A pode editar o rascunho P01, que lhe pertence, mas não pode editar o pedido P02 do cliente B.” Acrescenta as condições de estado e de atribuição que fazem parte do teu processo.

O guia sobre preparar o briefing de uma aplicação construída com IA ajuda a identificar estes percursos antes da implementação. Uma regra bem definida pode depois orientar o código, a revisão e os testes.

Prepara contas e registos que não dependem do administrador

Cria um ambiente de ensaio autorizado com contas que representem os utilizadores reais e dados que possas alterar sem consequências externas. Mantém sessões separadas para não confundires identidades. Testar sempre com a conta que criou o projeto pode esconder falhas que só aparecem quando alguém tem permissões limitadas.

No portal fictício, prepara as contas Cliente A e Cliente B, um Revisor e um Coordenador. Cria P01 para A e P02 para B. Junta um ficheiro fictício a cada pedido e um terceiro pedido de A já submetido, P03, para testar a diferença de estado.

Confirma primeiro que os dados existem e pertencem às contas certas. Se tentares abrir um identificador inventado e receberes uma recusa, ainda não demonstraste isolamento entre clientes. O objeto de teste precisa de existir, e a conta proprietária deve conseguir aceder-lhe quando a regra permite.

Usa perfis de navegador ou contextos de teste independentes. Antes de cada operação, confirma qual é a conta ativa. Duas janelas que partilham a mesma sessão podem levar-te a pensar que estás a testar duas pessoas quando estás sempre a usar a mesma identidade.

Guarda o estado inicial necessário para comparar os resultados. Neste exemplo, basta registar o dono, o estado e um campo de texto de cada pedido de teste. Evita copiar respostas completas com dados privados ou guardar credenciais nos relatórios. O objetivo é conseguir reproduzir a verificação com uma amostra controlada.

Cria uma matriz com casos permitidos e recusados

A matriz de testes deve mostrar a conta, o objeto, a operação e o resultado esperado. Inclui casos positivos para confirmar que a aplicação continua útil e casos negativos para verificar os limites. Uma solução que bloqueia tudo pode impedir acessos indevidos, mas também pode impedir o trabalho que deveria permitir.

Para o portal fictício, começa por estes casos. São propostas para executar no teu ambiente, não resultados de uma aplicação testada neste artigo. Os identificadores P01, P02 e P03 são apenas referências locais do exemplo e devem ser substituídos pelos registos de ensaio que preparaste.

Esta primeira matriz não cobre tudo. Acrescenta criação, eliminação, exportação e operações em lote se existirem na tua aplicação. Uma permissão de leitura não demonstra que a escrita está protegida, e a proteção de um pedido individual não prova o comportamento de uma exportação.

Também deves testar relações que mudam. Se o coordenador retirar a atribuição ao revisor, define quando o acesso deve terminar e confirma esse comportamento. A regra precisa de acompanhar o estado atual, em vez de depender apenas de uma condição verificada no primeiro login.

Confirma a autorização para lá dos botões

A interface ajuda a orientar o utilizador, mas a decisão de permitir uma operação tem de ser aplicada no local que controla os dados ou a ação. Verifica o pedido real que chega ao sistema. Um botão escondido ou desativado não prova que a mesma operação é recusada por outro caminho.

A OWASP distingue autenticação e autorização: reconhecer a identidade de alguém é diferente de verificar se essa pessoa pode realizar uma ação. A orientação recomenda validar permissões nos pedidos e não depender de controlos no navegador como decisão final de acesso.

No teu ambiente de teste, pede à pessoa responsável pelo desenvolvimento para repetir T04 através do caminho usado pela aplicação para guardar o pedido. Deve usar a sessão limitada de B e o identificador conhecido de P01, sem credenciais administrativas nem dados de terceiros fora do ensaio.

Observa a resposta, mas verifica também P01 com a conta autorizada. Uma mensagem de erro no ecrã não basta se a alteração já tiver sido aplicada antes de o erro aparecer. O caso só passa quando a operação indevida não produziu o efeito que a regra proíbe.

Faz o mesmo com campos que o navegador envia, como dono do registo, organização ou papel do utilizador. Alterar um valor enviado pelo cliente não deve conceder uma função nova. A aplicação precisa de determinar a autoridade a partir de informação confiável e das regras do processo.

Trata ficheiros, pesquisas e exportações como acessos próprios

Os dados privados podem sair por mais caminhos do que a página principal de um registo. Inclui anexos, pesquisa, contagens, exportações e notificações no mapa da aplicação. Para cada caminho, verifica que informação revela e que regra deveria aplicar, sem presumir que herda automaticamente a proteção do ecrã anterior.

No portal fictício, P01 pode estar protegido enquanto o respetivo PDF está disponível por uma ligação pública. Abre o ficheiro numa sessão sem autenticação e numa conta sem acesso ao pedido. Confirma o comportamento previsto para esse tipo de ligação, incluindo prazo e possibilidade de partilha quando existirem.

Uma ligação temporária pode continuar válida durante o período para o qual foi emitida. Por isso, a tua regra deve explicar o que acontece quando o acesso ao pedido é retirado. Não assumes que terminar uma sessão invalida automaticamente todos os ficheiros já descarregados ou todos os URLs anteriormente emitidos.

Na pesquisa, verifica se B encontra títulos, excertos ou identificadores de pedidos de A. Uma lista que esconde o detalhe pode continuar a revelar informação que deveria estar protegida. Nas exportações, confirma o conjunto completo de registos incluídos, usando a amostra pequena que preparaste.

Se existirem notificações, encaminha os ensaios para destinos de teste controlados. Verifica quem receberia a informação e em que momento. Uma alteração recusada não deve desencadear uma mensagem como se tivesse sido aprovada. Esta conferência liga a permissão ao efeito real do processo.

Revê as políticas de dados com a identidade certa

Quando a aplicação usa regras na base de dados, os testes precisam de exercer essas regras com identidades equivalentes às dos utilizadores. Uma consulta administrativa pode ter privilégios diferentes e produzir uma conclusão enganadora. Confirma como a tua tecnologia combina sessão, permissões de operação e políticas de acesso aos registos.

No Supabase, a documentação de Row Level Security explica a combinação de permissões e políticas, com regras para operações como leitura, inserção, atualização e eliminação. A configuração deve corresponder ao modelo de acesso da aplicação; ativar uma opção não substitui a revisão das políticas e dos testes.

A mesma documentação alerta para credenciais administrativas capazes de contornar RLS em determinadas condições. Por isso, um teste feito com acesso privilegiado não representa automaticamente o cliente A ou B. Regista a identidade efetiva usada no pedido e confirma o caminho normal da aplicação.

Não copies uma política genérica para todas as tabelas sem compreender o efeito. No exemplo, os pedidos pertencem a clientes e os comentários dependem também da atribuição de um revisor. As duas relações podem exigir condições diferentes, mesmo que os dados apareçam juntos no ecrã.

A proteção das credenciais é uma tarefa relacionada. O artigo sobre chaves e credenciais numa aplicação feita com IA explica onde guardar segredos e como evitar que cheguem ao navegador. Aqui, o objetivo é confirmar o que cada identidade consegue efetivamente fazer.

Testa mudanças de estado e de acesso

As permissões podem mudar durante a utilização da aplicação. Um rascunho é submetido, um revisor deixa de estar atribuído ou uma conta perde uma função. Inclui essas transições no ensaio e define o comportamento esperado para sessões já abertas, novos pedidos e operações que estavam em preparação.

No caso P03, abre o formulário de edição enquanto ainda é rascunho. Noutro contexto autorizado, submete o pedido. Depois tenta guardar a edição antiga. A aplicação deve aplicar a regra ao estado atual no momento adequado, sem confiar apenas no facto de o formulário ter sido aberto antes.

Este caso também exige uma mensagem útil. Se a gravação for recusada porque o pedido mudou, a pessoa deve perceber que precisa de atualizar a página ou seguir outro percurso. Não é necessário revelar detalhes internos para explicar o motivo operacional da recusa.

Testa a remoção de uma função com uma sessão já iniciada. Documenta a política prevista e o comportamento observado. Dependendo da arquitetura, a atualização de permissões e a duração de credenciais podem exigir medidas específicas; não prometas revogação imediata sem confirmar como foi implementada.

Se a aplicação permite transferir um pedido entre organizações, esse movimento precisa de testes próprios. Verifica o acesso anterior e o novo, os anexos e as operações associadas. Uma transferência visual na interface não prova que todas as relações foram atualizadas corretamente.

Pede à IA casos verificáveis e revê a evidência

Podes usar um agente de programação para mapear regras, propor testes e implementar correções no projeto autorizado. Dá-lhe a matriz e os limites do ensaio, incluindo as contas disponíveis. Pede resultados ligados a evidência concreta, distinguindo o que leu no código do que conseguiu executar no ambiente preparado.

Um pedido útil pode ser:

Revê o percurso de pedidos neste projeto. Usa a matriz de permissões aprovada e dados sintéticos. Identifica onde cada regra é aplicada, propõe os testes em falta e executa apenas os que cabem no ambiente de ensaio autorizado. Regista resultado esperado, observado e efeito nos dados. Não uses credenciais administrativas para simular contas limitadas nem apresentes inspeção de código como teste executado.

Adapta o pedido às capacidades disponíveis. O agente pode não ter acesso a um navegador autenticado, à base de dados de teste ou ao serviço que envia notificações. Nesse caso, deve deixar a verificação correspondente pendente, com uma forma clara de a concluir.

Revê os testes que o agente cria. Um teste que apenas repete a condição escrita no código pode passar sem demonstrar o percurso real. Para uma falha de acesso entre clientes, queres ver duas identidades, um objeto existente e a confirmação de que o acesso indevido foi recusado.

Depois de corrigir uma falha, repete o caso que a revelou e os casos próximos que a alteração pode afetar. O artigo sobre rever alterações de código sugeridas pela IA ajuda a ligar a mudança ao comportamento esperado e a preservar o que já funcionava.

Regista o que ficou demonstrado antes de abrir o acesso

O relatório final deve indicar o âmbito testado, a versão da aplicação e as verificações pendentes. Usa resultados observados para decidir se podes abrir o acesso previsto. Uma lista de testes aprovados ajuda a avaliar essa decisão, mas não deve ser apresentada como garantia de ausência de todas as falhas possíveis.

Para cada caso, guarda conta de teste, objeto, operação, resultado e efeito verificado. Acrescenta a data e a versão. Evita guardar tokens, palavras-passe ou respostas privadas no documento partilhado. A evidência deve permitir repetir o ensaio sem divulgar o acesso ao sistema.

Se um caso essencial falhar, corrige-o antes de disponibilizar o percurso afetado. Se uma parte não foi testada, identifica-a como tal e avalia se é necessária para a abertura prevista. Não transformes “não observámos um problema” em “verificámos que funciona”.

Mantém a matriz depois da publicação. Novas funções, integrações e alterações de estado podem mudar as regras de acesso. Reutilizar estes casos nas mudanças relevantes ajuda a detetar regressões e mantém a revisão ligada ao trabalho que os utilizadores precisam de realizar.

Como podes aprender isto no Laboratório da IA

No Laboratório da IA, podes aprender a construir projetos com critérios de verificação desde o início. As aulas semanais e os Zooms de acompanhamento semanais ajudam-te a trabalhar com agentes, compreender o percurso da aplicação e transformar dúvidas sobre acessos em casos concretos que consegues rever e testar.

Leva um mapa simples de utilizadores, dados e ações. A partir daí, podes preparar uma matriz de permissões e praticar num ambiente de ensaio, antes de abrir uma nova funcionalidade às pessoas que a vão utilizar.

Referências

O método usa materiais revistos do Laboratório sobre permissões, revisão de projetos, integrações e recuperação, com documentação pública consultada em 14 de outubro de 2026. O portal e a matriz são exemplos editoriais. Nenhuma aplicação, conta real ou base de dados foi auditada para produzir os testes descritos neste artigo.

• OWASP: Authorization Cheat Sheet.
• Supabase: Row Level Security.