Proteger os dados com permissões explícitas
A base de dados deve ter regras que indiquem quem pode consultar, criar, alterar e eliminar informação. Essas permissões precisam de acompanhar a estrutura do negócio, incluindo separação entre utilizadores e organizações. Uma aplicação com login pode continuar a expor dados se as regras de acesso forem demasiado abertas ou estiverem ausentes.
Imagina um portal onde duas empresas guardam pedidos. A pessoa da empresa A pode conhecer o endereço de um pedido da empresa B, mas isso não lhe dá autorização para o consultar. A separação tem de existir onde os dados são lidos, além de estar refletida na interface que cada pessoa vê.
Quando usamos uma base de dados com segurança ao nível da linha, as regras podem restringir os registos disponíveis para cada contexto. A documentação de RLS da Supabase explica esse mecanismo. O ponto que levo para a revisão é pedir regras explícitas e verificar o efeito com contas diferentes.
Também é preciso rever funções e formas indiretas de consultar dados. Uma página pode usar uma regra correta enquanto outra operação acede de forma privilegiada sem o filtro necessário. Por isso, a pergunta acompanha o percurso completo: que informação chega ao utilizador, por que caminho e com que autorização?
Confirmar autorização no servidor em cada ação
O servidor deve decidir se uma pessoa pode executar uma ação a partir de uma sessão verificada e das permissões guardadas pelo sistema. Campos enviados pelo navegador não podem atribuir poderes administrativos. A interface ajuda a orientar o utilizador, mas a decisão de permitir ou recusar tem de continuar válida fora dela.
Um botão escondido pode melhorar a experiência, mostrando apenas opções relevantes. Mesmo assim, alguém pode tentar chamar diretamente a operação de editar um pedido. O servidor precisa de recusar essa ação quando a sessão não tem permissão, independentemente de o pedido parecer igual ao que seria enviado por um administrador.
Um teste útil usa duas contas com funções diferentes. A primeira pode consultar um registo; a segunda pode alterá-lo. Verifica os dois comportamentos e tenta a edição com a conta de consulta. O resultado esperado deve estar escrito, para que futuras mudanças de interface não apaguem a proteção sem que alguém repare.
Na Sexta Ímpar #145, sobre desenvolvimento com Claude Code, a revisão de segurança acompanha a conversa sobre construção da aplicação. As cinco regras desta página são também critérios que exijo nos meus projetos. Não basta a ferramenta de IA dizer que tratou da segurança: quero evidência do comportamento.
Verificar acesso ao recurso pedido pelo identificador
Cada operação que recebe o identificador de um pedido, ficheiro ou outro recurso deve confirmar o acesso da sessão àquele elemento. Conhecer um endereço ou um número não equivale a autorização. Esta verificação tem de existir na leitura, edição, exportação e eliminação, conforme as ações disponíveis na aplicação em causa.
Pensa num download de uma proposta. O utilizador autenticado pode ter acesso à sua proposta e não às restantes. Se trocar o identificador no endereço, o sistema deve recusar o documento que não lhe pertence. A mesma lógica vale para imagens privadas, áudios, notas internas e resultados de uma tarefa de IA.
Este tipo de teste é especialmente importante quando a aplicação cresce. Uma primeira página pode estar protegida e uma nova exportação reutilizar o identificador sem repetir a verificação necessária. Rever as rotas por recurso ajuda a encontrar essas diferenças. A base de dados acrescenta proteção, e o código continua a validar a operação concreta.
No caso de agentes de IA empresariais, aplica o controlo antes de fornecer o contexto ao modelo. Se a sessão só pode consultar determinados pedidos, a ferramenta deve devolver apenas esses pedidos. O modelo não deve receber informação alheia com a instrução de a ignorar.
Manter chaves e credenciais fora do conteúdo público
As chaves que permitem aceder a serviços privados devem ficar no servidor e fora do código publicado, das páginas e dos registos partilhados. Dá a cada integração apenas o acesso necessário. A revisão precisa de incluir ficheiros, histórico de versões e respostas da aplicação, porque uma chave pode ser exposta por vários caminhos.
Uma variável usada no navegador pode ser vista por quem visita o site. Por isso, o pedido a um serviço que exige segredo deve passar por uma operação autorizada no servidor. O navegador recebe apenas o resultado permitido, sem receber a credencial usada para executar o trabalho em nome da aplicação.
Durante uma demonstração ou pedido de ajuda, também convém preparar o material. Uma captura de ecrã pode mostrar uma chave, um contacto ou informação de cliente. Nas aulas há decisões sobre o que posso mostrar. Esse cuidado deve continuar na documentação e nos exemplos enviados a ferramentas de IA durante o desenvolvimento.
Se uma credencial foi exposta, retirar o texto visível pode não chegar: a chave deve ser substituída e os locais de exposição revistos. Para a prevenção diária, prefiro acessos específicos por projeto e permissões limitadas. Assim, uma integração de envio não precisa de receber poderes administrativos sobre toda a plataforma.
Validar entradas e limitar o trabalho pedido à IA
A informação recebida deve ser validada antes de ser usada, guardada ou apresentada a outras pessoas. Define campos permitidos, formatos, tamanhos e limites de utilização. Conteúdo gerado ou importado também precisa de tratamento: uma resposta de IA continua a ser uma entrada que o sistema deve verificar antes de executar consequências.
Num formulário, confirma os campos no navegador para ajudar a pessoa e novamente no servidor para proteger a operação. A base de dados deve reforçar as regras que lhe dizem respeito. Em uploads, verifica o tipo e o tamanho do ficheiro, guarda-o no local adequado e controla quem o pode recuperar depois.
Quando apresentas HTML, tens de impedir que conteúdo recebido execute código indevido. Quando a IA lê uma página ou documento, trata instruções encontradas nesse material como conteúdo externo. O projeto OWASP para aplicações com modelos de linguagem inclui riscos como prompt injection e exposição de informação sensível.
Também defino limites de utilização e de custo. Uma funcionalidade que gera texto ou processa ficheiros pode ser abusada mesmo sem expor dados. O sistema deve conseguir recusar pedidos excessivos, limitar o contexto enviado e tornar visível uma falha, em vez de continuar a consumir recursos sem controlo.
Pedir evidência e manter a revisão ao longo do projeto
Uma revisão útil entrega exemplos do que foi testado, resultados observados e limites que continuam por resolver. Repete as verificações relevantes quando mudam acessos, integrações ou dados. A segurança acompanha a manutenção da aplicação, com responsáveis e critérios claros, porque uma alteração pequena pode abrir um percurso que antes não existia.
Peço testes negativos: uma conta que não consegue ler o pedido de outra, uma operação administrativa recusada e um upload fora dos limites rejeitado. Também quero verificar que o utilizador legítimo consegue continuar o seu trabalho. Um sistema que bloqueia tudo não está pronto só porque deixou de expor informação.
Na documentação de segurança do Claude Code, encontras cuidados sobre permissões da ferramenta e conteúdo não confiável. Distingo essa camada da segurança do produto que entregamos. O artigo sobre planeamento de aplicações e a página de desenvolvimento com IA ajudam a ligar estas verificações à construção.
Se queres preparar a tua equipa para estas decisões, consulta a formação de IA para empresas. Para discutir implementação e necessidades do projeto, apresenta o contexto à SpartAds. Estes critérios orientam a conversa; uma avaliação concreta depende sempre do sistema, dos dados e das ações que ele permite.