Confirma quem pode ler e alterar a base de dados
A primeira verificação é perceber se os dados têm proteção própria e se as permissões correspondem às operações necessárias. Em projetos com Supabase, confiro RLS e políticas explícitas, juntamente com os acessos concedidos. Peço testes de leitura e escrita com utilizadores comuns, em vez de aceitar apenas a indicação de que está tudo ativo.
Imagina uma aplicação para uma empresa que produz brindes personalizados. Existem pedidos, ficheiros de desenho e notas internas da produção. Uma pessoa pode precisar de consultar o estado da sua encomenda sem poder ler observações destinadas à equipa. Essa distinção deve continuar válida quando os dados são consultados pelo percurso previsto.
A revisão deve identificar as tabelas relevantes, as operações permitidas e a evidência de que os restantes acessos são recusados. Se o teste usa uma conta privilegiada, pede que isso seja declarado. Os poderes dessa conta podem ser diferentes dos de quem vai utilizar a aplicação e esconder uma configuração inadequada.
Também peço atenção às formas alternativas de consultar os mesmos dados, como vistas ou funções criadas para facilitar relatórios. Uma proteção aplicada à tabela principal não dispensa verificar a forma como esses caminhos estão configurados. O resultado deve permitir explicar quem consegue obter cada conjunto de informação e por que razão.
Esta regra entra no planeamento da aplicação antes de programar, porque depende das relações entre os dados e as pessoas. Se só começas a discutir essas relações no momento da publicação, a revisão pode revelar uma decisão de produto que ficou por tomar e já atravessa vários percursos da aplicação.
Para preparar o próximo passo, consulta Segurança de aplicações desenvolvidas com IA.
Verifica se o servidor decide as permissões e valores relevantes
A segunda verificação procura decisões importantes que estejam a confiar apenas no navegador. A identidade e a autorização devem ser confirmadas no servidor, e os valores que determinam uma operação precisam de uma origem válida. O conteúdo de um formulário é informação recebida, não uma prova de que a ação está autorizada.
Na encomenda de brindes, o navegador pode mostrar um preço e uma opção de aprovação. Isso não significa que deva determinar sozinho o valor aceite ou a pessoa que pode aprovar. O sistema precisa de consultar as regras e a informação verificadas que sustentam aquela operação específica no projeto.
Pede ao agente que identifique os campos recebidos do utilizador que poderiam afetar uma decisão: identidade, organização, nível de acesso ou estado de aprovação. A revisão deve mostrar como cada um é tratado. Não basta esconder esses campos no ecrã se o processamento posterior confiar neles sem uma confirmação adequada.
Nos testes, interessa observar que uma entrada incompatível com a regra é recusada antes de produzir o efeito. Uma mensagem visual pode estar correta enquanto o registo fica errado. Por isso, a evidência precisa de incluir o resultado guardado ou a ausência de alteração, conforme o comportamento esperado naquele caso.
Exige autorização sobre cada recurso pedido
A terceira verificação confirma que conhecer o identificador de um recurso não basta para o consultar ou alterar. Cada pedido deve relacionar a identidade verificada com o recurso e a ação pretendida. A regra precisa de ser aplicada também a anexos e exportações, sempre que estes transportem informação que deva estar protegida.
No exemplo dos brindes, duas empresas podem ter encomendas na mesma aplicação. Um utilizador legítimo da primeira continua sem autorização para consultar o desenho enviado pela segunda. A revisão precisa de acompanhar o acesso à encomenda e ao respetivo ficheiro, incluindo o serviço onde esse ficheiro está guardado.
Prepara dados fictícios que permitam demonstrar essa separação em ambiente autorizado. O teste deve mostrar que o acesso correto funciona e que o incorreto é recusado, sem usar documentos reais de clientes. Assim consegues observar a regra com clareza e repetir a verificação quando o percurso sofrer alterações relevantes.
Esta é uma aplicação concreta de testar antes de entregar uma automação. A validação acompanha a consequência de negócio: quem recebe o quê e quem pode mudar o estado do trabalho. O relatório deve distinguir um controlo encontrado no código de um comportamento que foi efetivamente exercitado.
Procura segredos no que pode sair do servidor
A quarta verificação procura credenciais que possam aparecer no código partilhado, nos ficheiros enviados ao navegador ou nos registos de execução. Chaves privadas devem ficar nos mecanismos adequados de configuração do servidor. Peço um relatório que identifique as localizações e o risco sem voltar a imprimir o valor do segredo encontrado.
Uma integração de envio de mensagens pode precisar de uma credencial privada, mas o utilizador da aplicação não precisa de a receber. O servidor executa a operação autorizada e devolve o resultado necessário. Se a chave aparecer no código descarregado pelo navegador, o facto de o repositório ser privado não resolve essa exposição.
Na preparação do ambiente de trabalho com Claude Code, separa exemplos de configuração dos valores reais. Um ficheiro com nomes de variáveis e espaços por preencher pode orientar a instalação sem revelar credenciais. A revisão deve confirmar que os ficheiros com segredos não foram incluídos no material destinado a partilha.
Se for encontrada uma credencial exposta, retirar a linha do código não encerra a questão. É preciso tratar a credencial comprometida e os locais onde possa continuar disponível, com um responsável pela substituição e pela continuidade do serviço. O relatório deve registar ações concluídas e pendentes, sem apresentar limpeza visual como resolução completa.
Valida as entradas antes de as usar
A quinta verificação acompanha os dados recebidos pela aplicação e confirma que são aceites apenas nas condições previstas. Peço validação no servidor, limites adequados e regras coerentes com a operação. A ajuda no formulário melhora a experiência, mas não substitui os controlos que protegem o processamento e o armazenamento da informação.
Uma quantidade de brindes deve respeitar o tipo e os limites definidos para a encomenda. Um ficheiro de desenho deve cumprir as condições de formato e tamanho aceites. As regras precisam de refletir o que o negócio consegue tratar, com uma resposta clara quando a informação recebida não serve para concluir o pedido.
Validar não significa resolver todos os riscos com uma única verificação de texto. Conteúdo apresentado como HTML, consultas à base de dados e ficheiros carregados exigem tratamento apropriado ao contexto em que serão usados. Pede ao agente que explique esses destinos e os controlos correspondentes, sem transformar um filtro genérico numa garantia.
No fecho, quero cinco respostas ligadas a evidência, com a versão revista, os testes executados e as limitações conhecidas. Uma falha que afete dados ou ações importantes precisa de ser resolvida antes da publicação prevista. Depois de corrigir, repete as verificações afetadas para que a decisão final corresponda ao código que será entregue.