Segurança no vibe coding: uma lista de 10 minutos antes de chegarem os utilizadores reais

O vibe coding não é seguro por omissão, nem inseguro por natureza: uma aplicação web gerada por IA é tão segura quanto as verificações que alguém lhe fez. As mesmas poucas falhas repetem-se nas apps criadas com criadores de apps com IA: dados legíveis por qualquer pessoa, chaves secretas no navegador, regras aplicadas apenas na interface. Cada uma pode ser testada por quem não é programador em poucos minutos, e cada uma tem um prompt de seguimento que a corrige.

Esta lista é para fundadores, freelancers e pequenas equipas prestes a dar acesso a um primeiro utilizador real a uma app criada com um criador de apps com IA. Se o método for novo para si, comece pelo nosso guia de vibe coding. Se a sua app usa o Supabase, os detalhes do lado da base de dados estão no nosso guia sobre a row level security do Supabase.

Porque é que as apps criadas com IA falham sempre da mesma maneira

Um criador com IA otimiza para uma app que funcione no ecrã, e um ecrã que funciona não diz nada sobre quem mais pode aceder aos dados por trás. Quando pede "um dashboard onde cada cliente vê as suas faturas", o modelo constrói primeiro o ecrã. Saber se a base de dados se recusa a devolver as faturas de outros clientes é um trabalho à parte, e só é feito se o prompt ou as predefinições do criador o pedirem.

Um exemplo público mostra a forma do problema. Em 2025, foi publicado um registo de vulnerabilidade (CVE-2025-48757) que descreve políticas de row level security insuficientes em sites gerados com o Lovable, até 2025-04-15, que permitiam a visitantes não autenticados ler ou escrever em tabelas. A entrada da National Vulnerability Database nota também que o fornecedor contesta a conclusão e afirma que cada cliente é responsável por proteger os dados da sua própria aplicação. As duas afirmações apontam para a mesma conclusão prática: quem publica a app tem de verificar as suas regras de acesso, seja qual for a ferramenta que a escreveu.

As sete falhas num relance

A maioria destas falhas corresponde ao OWASP Top 10, a lista de referência dos riscos das aplicações web, na edição de 2025. A correspondência abaixo usa os nomes das categorias dessa lista.

1. Row level security em falta

Com um backend Supabase, o navegador fala com a base de dados através de uma API pública, por isso a única coisa que separa um visitante das suas tabelas é a row level security (RLS): regras associadas a cada tabela que dizem que linhas um utilizador pode ler ou escrever. Uma tabela sem RLS ativada pode ser lida por quem tiver a chave pública, e essa chave está no navegador por conceção. O Supabase explica o mecanismo na sua documentação sobre row level security.

O teste leva cinco minutos. Crie duas contas, A e B, com emails diferentes. Como A, crie um registo (uma fatura, uma nota, um projeto). Termine a sessão, inicie sessão como B e procure o registo de A em todas as listas e pesquisas. Depois abra as ferramentas de programador do navegador, vá ao separador Rede, recarregue a página, clique num pedido à base de dados e leia a resposta: só pode conter as linhas de B. Por fim, termine a sessão e recarregue a mesma página: os pedidos devem devolver nada ou um erro.

Prompt de seguimento: "Lista todas as tabelas da base de dados indicando se a row level security está ativada e que políticas se aplicam. Ativa a RLS em todas as tabelas que não a têm e escreve políticas para que um utilizador só possa fazer select, insert, update e delete em linhas onde user_id seja igual ao seu próprio id. Mostra-me as políticas e explica qualquer tabela que tenhas deixado pública de propósito."

2. Chaves secretas no frontend

Tudo o que é enviado para o navegador é público, incluindo todas as chaves que se encontram no código-fonte da página. Algumas chaves são feitas para ser públicas (a chave pública do Supabase, protegida pela RLS). Outras não: chaves secretas de pagamento, chaves de fornecedores de IA, chaves de serviços de email, a chave service role da base de dados. Um visitante que copie uma delas pode enviar emails em seu nome ou fazer pedidos de IA na sua fatura.

Para testar, abra a app publicada, abra as ferramentas de programador, vá aos separadores Rede e Origens e procure os primeiros caracteres de cada segredo que usa (por exemplo "sk_" para uma chave de pagamento) e o nome de qualquer fornecedor. Procure também no código do projeto e no repositório do GitHub, se o exportar. Um segredo num repositório público conta como divulgado mesmo depois de o apagar.

Prompt de seguimento: "Procura em todo o projeto chaves de API, tokens e segredos no código do cliente. Move todas as chamadas que precisem de um segredo para uma edge function do lado do servidor, lê a chave a partir de variáveis de ambiente e nunca uses a chave service role no navegador. Lista o que moveste." Se um segredo ficou exposto, rode-o no fornecedor: apagar o código não cancela a chave.

3. Autorização verificada só na interface

Esconder um botão é uma escolha de design, não uma permissão. Se o botão de apagar estiver escondido para o perfil "leitor" mas a base de dados aceitar o pedido de apagar na mesma, qualquer leitor com as ferramentas de programador pode enviá-lo. As regras têm de ser aplicadas onde os dados vivem, com a interface a limitar-se a refleti-las.

Para testar, inicie sessão com o perfil mais baixo, faça uma ação permitida, como ler, e no separador Rede copie esse pedido (clique direito, "Copy as fetch"). Edite-o para algo proibido, como mudar o id de outro registo ou um campo de perfil, e execute-o na consola. Se resultar, a regra existe apenas na interface. Verifique também que um utilizador não consegue editar o seu próprio campo de perfil ou de plano.

Prompt de seguimento: "Para cada perfil, lista as ações que pode executar em cada tabela. Aplica-as com políticas da base de dados, não apenas na interface. Impede os utilizadores de atualizar as suas próprias colunas role, plan ou user_id."

4. Páginas de admin acessíveis por URL

Uma página de admin que simplesmente não aparece no menu continua acessível a quem adivinhar o endereço. A página tem de verificar o perfil antes de mostrar o que quer que seja, e os dados por trás dela têm de estar protegidos pelas políticas do ponto 1.

Para testar, liste as suas rotas de admin (/admin, /settings/users, /dashboard/all). Abra cada uma numa janela privada sem sessão e depois com sessão como utilizador normal. Deve cair numa página de início de sessão ou de "acesso negado", e o separador Rede não deve mostrar dados de admin em nenhuma resposta.

Prompt de seguimento: "Protege todas as rotas de admin para que só utilizadores com o perfil admin as possam abrir, redireciona todos os outros e garante que as consultas de dados dessas páginas também falham para quem não é admin."

5. Uploads de ficheiros sem validação

Um campo de upload que aceita qualquer ficheiro, de qualquer tamanho, para uma pasta pública permite que estranhos aloje conteúdos no seu domínio e encham o seu armazenamento. Os documentos privados (contratos, CVs, faturas) não podem ser legíveis através de uma ligação que se adivinha.

Para testar, envie um ficheiro de tipo errado (um executável renomeado para .jpg) e um ficheiro muito grande. Depois copie a ligação de um documento privado enviado e abra-a numa janela privada. Se abrir, o bucket é público.

Prompt de seguimento: "Restringe os uploads a estes tipos de ficheiro: [lista] e a um tamanho máximo de [x MB], verificados no envio. Torna o bucket privado, acrescenta políticas de armazenamento para que um utilizador só possa ler os seus próprios ficheiros e serve os ficheiros através de ligações assinadas que expiram."

6. Dependências desatualizadas

Uma app é feita de centenas de pacotes de código aberto, e um pacote com uma falha conhecida é uma porta de entrada pronta a usar. A OWASP agrupa isto em falhas na cadeia de fornecimento de software. A IA pode também escolher uma versão antiga de um pacote que aprendeu em exemplos mais velhos.

O teste é um comando no projeto exportado: "npm audit" lista as vulnerabilidades conhecidas nos pacotes instalados. Se não o conseguir executar, peça à IA a revisão equivalente. Volte a fazê-lo antes de cada lançamento importante.

Prompt de seguimento: "Verifica as dependências quanto a vulnerabilidades conhecidas e versões principais desatualizadas. Atualiza as que têm correção, evita alterações incompatíveis e lista o que não conseguiste atualizar e porquê. Remove os pacotes que a app não usa."

7. Sem limites de pedidos no registo e nos endpoints de IA

Sem limites, um script pode criar milhares de contas falsas ou chamar o seu endpoint de IA até crescer a fatura do fornecedor, e não o número de utilizadores. Dois sítios contam mais: o registo (e a redefinição de palavra-passe, que envia emails) e qualquer função que chame uma API paga.

Para testar, envie o mesmo pedido de registo ou de IA muitas vezes seguidas a partir das ferramentas de programador ou de um script simples e veja se alguma coisa o abranda ou bloqueia. Verifique também que os endpoints de IA exigem um utilizador com sessão e que um utilizador não pode enviar um prompt de 10 MB.

Prompt de seguimento: "Exige início de sessão em todas as edge functions que chamam uma API paga, limita cada utilizador a [n] chamadas por hora, limita o tamanho da entrada e devolve um erro claro quando o limite for atingido. Ativa a confirmação por email e um captcha no registo."

Dados pessoais e RGPD

Se os seus utilizadores estão na Europa, a app guarda dados pessoais e a responsabilidade é sua, seja qual for a ferramenta que criou a app. As falhas de segurança acima são também a via habitual das fugas de dados pessoais. Além delas, verifique o básico: uma política de privacidade que corresponda ao que a app realmente recolhe, uma forma de apagar a conta e os dados de um utilizador, e nenhum dado pessoal em registos ou análises que não tenha querido enviar. O nosso guia sobre o RGPD e as apps no-code com IA trata a parte jurídica com mais detalhe.

Prompt de seguimento: "Acrescenta uma funcionalidade de eliminação de conta que remova as linhas e os ficheiros do utilizador, lista todos os campos de dados pessoais que guardamos e porquê, e garante que nenhum dado pessoal é escrito nos registos."

O que o Cadrant faz por omissão e o que não faz

O Cadrant, o nosso criador, gera apps React com um backend Supabase na sua própria conta Supabase. Por omissão, a IA escreve as migrações da base de dados com políticas de row level security nas tabelas por utilizador, incluindo políticas de armazenamento, e pode inspecionar o esquema e as políticas atuais antes de os alterar. As chaves secretas não são colocadas no código do cliente: integrações como o Stripe, a OpenAI ou serviços de email passam por edge functions do Supabase, com os segredos guardados como variáveis de ambiente. A nossa documentação descreve-o nas páginas sobre edge functions e variáveis de ambiente.

As predefinições reduzem o número de erros; não substituem o teste. Um prompt pode continuar a pedir uma tabela pública, um modelo pode continuar a esquecer uma política numa tabela que acrescente mais tarde, e nenhum criador revê as suas regras de negócio por si. Faça o teste das duas contas depois de cada alteração grande, seja qual for a ferramenta.

Lista de verificação antes do lançamento

Quando a app trata pagamentos, dados de saúde ou outra informação regulamentada, vale a pena o custo de uma revisão única por um profissional de segurança: esta lista apanha as falhas comuns, não todas as falhas. Para a parte da construção, veja a nossa página do criador de apps com IA.