Construir uma ferramenta interna, um portal de clientes ou uma pequena aplicação com IA nunca foi tão rápido. Em dias, uma PME consegue ter um sistema de orçamentos, uma área reservada ou um CRM à medida. O problema é que a velocidade esconde um risco: o código funciona, mas não é seguro.
Os números são claros. O relatório de 2026 da Veracode sobre código gerado por IA, que acompanhou mais de cem modelos, encontrou uma taxa média de aprovação em testes de segurança de 56%, praticamente igual à do ano anterior. Ou seja, cerca de quatro em cada dez amostras de código gerado por IA falharam testes de segurança.
E não é teoria. Em 2025, uma falha de configuração em aplicações criadas com o Lovable (registada como CVE-2025-48757) deixou expostos dados de pelo menos 170 projetos: emails, telefones, estados de pagamento e chaves de API, acessíveis a qualquer pessoa.
Este guia é para quem encomenda, aprova ou constrói sistemas com IA. Explica, em linguagem de gestão, as 20 verificações que deve exigir antes de pôr dados de clientes num sistema, o ciclo de auditoria com IA e o que a lei espera de si.
Os números
Porque é que isto não é um tema técnico
Termos usados neste artigo
- Vibe coding: construir software descrevendo o que se quer em linguagem natural, enquanto a IA escreve o código.
- Chave de API / segredo: credencial que dá acesso a um serviço (base de dados, pagamentos, email). Quem a tiver, age em nome da empresa.
- Rotação de chaves: substituir uma chave por uma nova e desativar a antiga.
- RLS (Row Level Security, segurança ao nível da linha): regras da base de dados que garantem que cada utilizador só vê e altera os registos que lhe pertencem.
- Injeção de SQL: ataque em que texto escrito num formulário é interpretado como uma instrução à base de dados.
- XSS (cross-site scripting): ataque em que código malicioso é inserido numa página e executado no navegador de outros utilizadores.
- Dependência: biblioteca de terceiros usada pelo sistema. Se tiver uma falha conhecida, o sistema herda-a.
- HTTPS / HSTS: ligação cifrada entre o navegador e o servidor, e a regra que obriga o navegador a usá-la sempre.
- Varredura de segurança: análise automática do código à procura de segredos expostos, dependências vulneráveis e padrões perigosos.
Porque é que a IA gera código inseguro
Não é falta de capacidade. É falta de contexto. A IA escreve código que funciona no caso normal: o formulário envia, a página carrega, o login entra. A segurança está quase sempre nos casos que ninguém pediu: o que acontece se outro utilizador alterar o identificador no endereço? Se alguém enviar um texto de 10 MB? Se a chave da base de dados ficar no código do navegador?
Infografia
“Funciona” não é o mesmo que “é seguro”
O caminho feliz
- O cliente preenche o formulário e recebe a confirmação
- O login com a palavra-passe certa entra
- A lista mostra os pedidos
Tudo o resto
- Ver os pedidos de outro cliente mudando um número no endereço
- Tentar mil palavras-passe por minuto
- Ler a chave da base de dados no código da página
As 20 verificações, por camada
Agrupei as verificações em cinco camadas. A coluna da direita é o que deve perguntar a quem construiu o sistema (ou pedir à IA que confirme).
Infografia
As cinco camadas de segurança
1. Segredos
| # | Verificação | O risco, em linguagem simples | Pergunta a fazer |
|---|---|---|---|
| 1 | Rodar qualquer chave que tenha sido exposta | Uma chave que apareceu num print, numa conversa ou num repositório deve ser considerada comprometida, mesmo que tenha sido apagada | “Alguma chave foi alguma vez partilhada? Já foi substituída?” |
| 2 | Limpar segredos do histórico de versões | Apagar o ficheiro não apaga a chave das versões anteriores | “O histórico do repositório foi verificado?” |
| 3 | Só chaves públicas no navegador | Tudo o que vai para o navegador pode ser lido por qualquer pessoa. Uma chave de serviço no navegador dá acesso total à base de dados | “Que chaves estão no código que corre no navegador?” |
2. Base de dados
| # | Verificação | O risco | Pergunta a fazer |
|---|---|---|---|
| 4 | Segurança ao nível da linha (RLS) ativa em todas as tabelas | Sem ela, a chave pública lê a tabela inteira. Foi a causa da falha do Lovable | “Todas as tabelas têm RLS ativa?” |
| 5 | Regras que comparam o dono do registo | “Qualquer utilizador autenticado” vê os dados de todos | “Testaram com duas contas diferentes?” |
| 6 | Campos de controlo protegidos | Se o navegador pode escrever qualquer campo, pode alterar preços, permissões ou o dono | “O cliente consegue alterar campos como preço ou perfil?” |
| 7 | Dados sensíveis cifrados | Dados em texto simples agravam qualquer acesso indevido | “Que dados estão cifrados?” |
| 8 | Consultas parametrizadas | Montar consultas juntando texto permite injeção de SQL | “Há consultas construídas com texto do utilizador?” |
3. Acesso e sessões
| # | Verificação | O risco | Pergunta a fazer |
|---|---|---|---|
| 9 | Permissões verificadas no servidor | Esconder um botão não impede ninguém de chamar a função diretamente | “A permissão é verificada no servidor em todas as rotas?” |
| 10 | Palavras-passe com cifra forte (ou login de um serviço especializado) | Um vazamento com palavras-passe legíveis afeta outros serviços onde a pessoa as repetiu | “Usam um serviço de autenticação próprio para isso?” |
| 11 | Cookies de sessão protegidos | Um script na página pode roubar a sessão | “Os cookies estão marcados como seguros e inacessíveis a scripts?” |
| 12 | Limite de tentativas de login | Sem limite, as palavras-passe são testadas em massa | “O que acontece à 10.ª tentativa falhada?” |
| 13 | Proteção contra robôs nos registos | Formulários abertos geram contas falsas em massa | “Há verificação humana e confirmação por email?” |
4. Dados que entram e saem
| # | Verificação | O risco | Pergunta a fazer |
|---|---|---|---|
| 14 | Validação no servidor | Campos sem validação aceitam valores impossíveis ou textos gigantes | “Que validação existe no servidor, além do formulário?” |
| 15 | Limpeza do que é mostrado | Texto de utilizadores mostrado sem tratamento permite XSS | “Os comentários ou nomes dos clientes são tratados antes de aparecerem?” |
| 16 | Envio de ficheiros controlado | Ficheiros sem limite podem encher o servidor ou ser executados | “Há limite de tamanho e de tipo de ficheiro?” |
| 17 | Devolver só os campos necessários | Respostas com o registo inteiro expõem dados que o ecrã nem mostra | “A aplicação devolve só os campos que usa?” |
5. Publicação
| # | Verificação | O risco | Pergunta a fazer |
|---|---|---|---|
| 18 | Cabeçalhos de segurança | Sem eles, o site pode ser embutido noutra página para enganar utilizadores | “Os cabeçalhos de segurança estão configurados?” |
| 19 | HTTPS obrigatório | Sem ele, palavras-passe e sessões circulam sem cifra | “Todo o acesso é redirecionado para HTTPS?” |
| 20 | Dependências verificadas | Bibliotecas com falhas conhecidas são uma porta de entrada comum | “Há alertas automáticos de dependências vulneráveis?” |
O caso mais comum: bases de dados Supabase
Muitas aplicações feitas com IA (incluindo as do Lovable) usam o Supabase como base de dados. A documentação oficial é clara em três pontos:
- A RLS deve estar ativa em todas as tabelas expostas. Sem ela, quem tiver acesso à tabela pode ler e escrever.
- Com RLS ativa e sem regras, nada é acessível através da chave pública. É o comportamento certo: abre-se o acesso uma regra de cada vez.
- A chave secreta (ou a antiga chave
service_role) ignora a RLS. Nunca deve estar no navegador.
Um detalhe técnico com consequências práticas: uma regra como “o utilizador só vê os seus registos” falha em silêncio para visitantes sem sessão iniciada. A documentação recomenda escrever a condição de forma explícita, verificando primeiro se existe um utilizador autenticado.
O ciclo de auditoria com IA
A IA que gerou o problema também ajuda a encontrá-lo, desde que o processo esteja bem montado. O ciclo tem cinco passos:
Infografia
Varrer, corrigir, rodar e voltar a varrer
Ferramentas para a varredura:
| Ferramenta | O que encontra | Custo |
|---|---|---|
| Deteção de segredos do GitHub | Chaves e tokens no código e no histórico | Gratuita em repositórios públicos; em repositórios privados de organizações exige o GitHub Secret Protection (pago) |
| Alertas de dependências do GitHub | Bibliotecas com falhas conhecidas | Disponíveis nos planos do GitHub |
npm audit (projetos JavaScript) |
Dependências vulneráveis | Gratuito |
| Plugins de segurança do Claude Code | Revisão do código à procura de padrões de risco | Incluídos no consumo do plano |
O pedido de auditoria
Com o relatório da varredura na pasta do projeto, ou mesmo sem ele, este pedido organiza o trabalho:
Faz uma auditoria de segurança a este projeto. NÃO corrijas nada ainda.
Verifica, por esta ordem: segredos (chaves no código, no navegador e no histórico),
base de dados (RLS em todas as tabelas, regras que comparam o dono, campos de controlo protegidos),
acesso (permissões no servidor, limite de tentativas de login, cookies),
dados (validação no servidor, limpeza do que é mostrado, envio de ficheiros, campos devolvidos)
e publicação (HTTPS, cabeçalhos, dependências).
Para cada problema: ficheiro e linha, o risco numa frase em linguagem simples, gravidade (crítica, alta, média, baixa)
e o que fazer. Ordena do mais grave para o menos grave.
Separa o que podes corrigir sozinho do que depende de mim (por exemplo, rodar chaves).
Se uma verificação não se aplicar a este projeto, diz isso em vez de inventar um problema.
Depois de rever a lista, peça as correções uma de cada vez, mostrando a alteração antes de a aplicar, e no fim peça para registar no CLAUDE.md as regras que evitam repetir os mesmos erros.
Como rodar uma chave sem parar o sistema
Infografia
A ordem certa (trocar a ordem desliga o sistema)
- MapearOnde é usada a chave: servidor, automações, outros sistemas.
- Gerar a novaNo painel do serviço (base de dados, pagamentos, email).
- SubstituirEm produção, em variáveis de ambiente, nunca no código.
- ConfirmarTestar que tudo funciona com a chave nova.
- Revogar a antigaSó agora. E depois limpar o histórico do repositório.
Prioridades: o que fazer hoje e o que pode esperar
| Quando | O quê |
|---|---|
| Hoje | Chaves, tokens e palavras-passe expostos. RLS desativada em tabelas com dados de clientes |
| Esta semana | Dependências vulneráveis em uso. Falhas em páginas e funções acessíveis ao público |
| Quando possível | Dependências usadas só em desenvolvimento. Avisos em código que só corre localmente |
| Registar e seguir | Falsos positivos confirmados, com o motivo anotado |
O que a lei espera de si
Se o sistema trata dados pessoais de clientes ou colaboradores, aplica-se o RGPD, independentemente de o código ter sido escrito por uma pessoa ou por uma IA:
- A responsabilidade é da empresa que trata os dados, não da ferramenta de IA nem, em exclusivo, do fornecedor que construiu o sistema.
- O artigo 32.º exige medidas técnicas e organizativas adequadas ao risco. As verificações deste artigo são exatamente isso.
- O artigo 33.º obriga a notificar a autoridade de controlo (em Portugal, a CNPD) de uma violação de dados pessoais sem demora injustificada e, sempre que possível, até 72 horas depois de ter conhecimento dela.
Checklist
O que exigir a quem constrói o seu sistema
- Relatório de varredura de segurança antes da entrega
- Teste com duas contas a provar que os dados não se cruzam
- Lista de chaves usadas e onde estão guardadas
- Confirmação de que nenhuma chave secreta está no navegador
- Alertas automáticos de dependências ativos
- Contas (alojamento, base de dados, repositório) em nome da empresa
- Plano de resposta se houver uma violação de dados
Os limites da auditoria automática
Duas notas de honestidade, para não criar falsa segurança:
- Zero alertas não significa sistema seguro. As ferramentas automáticas encontram padrões conhecidos. Não sabem, por exemplo, que uma página devia ser privada, nem detetam erros de lógica nas permissões.
- Corrigir não desfaz uma exposição. Uma chave que esteve exposta tem de ser rodada, mesmo depois de removida do código.
Repita a varredura antes de cada entrega importante e depois de sessões longas de trabalho com IA, que é quando mais alterações se acumulam sem revisão.
Perguntas frequentes
O código gerado por IA é inseguro?
Não necessariamente, mas falha com frequência em testes de segurança. O relatório de 2026 da Veracode encontrou uma taxa média de aprovação de 56% em código gerado por IA, praticamente igual à do ano anterior. A IA escreve código que funciona no caso normal; a segurança depende de verificações que é preciso pedir explicitamente e confirmar.
O que aconteceu com as aplicações do Lovable em 2025?
Uma falha de configuração na segurança ao nível da linha (RLS) da base de dados, registada como CVE-2025-48757, permitiu a pessoas sem autenticação ler e alterar dados de pelo menos 170 projetos criados com o Lovable, incluindo emails, telefones, estados de pagamento e chaves de API. O Lovable acrescentou depois um verificador de segurança.
O que é a RLS e porque é tão importante?
A segurança ao nível da linha (Row Level Security) é um conjunto de regras na base de dados que garante que cada utilizador só vê e altera os registos que lhe pertencem. Em bases de dados como o Supabase, se estiver desativada, a chave pública usada pelo navegador pode dar acesso à tabela inteira.
Uma chave de API exposta num repositório privado também tem de ser substituída?
Sim. Uma chave que esteve exposta, mesmo num repositório privado, numa conversa ou numa captura de ecrã, deve ser considerada comprometida. A ordem certa é gerar a nova, substituí-la em produção, confirmar que tudo funciona e só depois revogar a antiga.
Quem é responsável se um sistema feito com IA expuser dados de clientes?
Ao abrigo do RGPD, a responsabilidade é da empresa que trata os dados. Deve adotar medidas de segurança adequadas e, em caso de violação de dados pessoais, notificar a CNPD sem demora injustificada e, sempre que possível, até 72 horas depois de ter conhecimento. Este artigo não constitui aconselhamento jurídico.
A IA consegue fazer a auditoria de segurança sozinha?
Ajuda muito: lê relatórios de varredura, ordena problemas por risco e propõe correções. Mas não substitui uma revisão humana, sobretudo nas regras de permissões e de negócio. Peça sempre a auditoria sem correções primeiro, aprove cada alteração e volte a varrer no fim.
Tem um sistema feito com IA a tratar dados de clientes e não sabe se está seguro? Agende uma conversa gratuita de 30 minutos e vemos juntos os riscos e as prioridades.
Informação verificada em outubro de 2026 no relatório da Veracode, na análise da CVE-2025-48757, na documentação de RLS do Supabase e na documentação de deteção de segredos do GitHub. Este artigo não constitui aconselhamento jurídico.
Artigo publicado em jorgerosendo.com — IA, Marketing, SEO e Produtividade.