O Vibe Coding é Seguro? Os Riscos Reais e o Que Verificar Antes de Publicar

O vibe coding é seguro para ferramentas pessoais e protótipos, e pode ser seguro para aplicações reais com utilizadores reais, mas só se acrescentar as verificações que o "descreva e veja se funciona" dispensa. Os problemas perigosos são invisíveis no ecrã: utilizadores que conseguem abrir os dados uns dos outros, chaves secretas guardadas no navegador e formulários públicos sem limites. Este guia explica os riscos que causam problemas a sério, como tratar os segredos, quanta revisão é necessária e uma verificação de 30 minutos a fazer antes de publicar.

Para a lista técnica completa, veja a nossa lista de verificação de segurança para aplicações construídas com IA. Esta página é a versão mais curta e prática, para quem não lê código.

Porque é que o vibe coding tem riscos próprios

Quando faz vibe coding, avalia a aplicação ao usá-la. Isso apanha botões que não funcionam e layouts feios. Não apanha problemas que só aparecem quando alguém usa a aplicação de forma diferente da sua: um desconhecido, um bot, um utilizador curioso a editar um endereço web.

Os modelos de IA escrevem código plausível, e a maior parte está bem. Mas otimizam para o que pediu — "faz o dashboard mostrar os meus projetos" — e podem não acrescentar a proteção que não pediu — "e nenhum dos outros". A solução não é deixar de fazer vibe coding. É pedir explicitamente as proteções e depois testá-las.

Qual é o risco da sua aplicação? Uma escala rápida

Seja honesto sobre em que linha se encontra. Muitas aplicações começam na primeira linha e passam para a terceira sem que ninguém tenha decidido isso.

Os riscos que realmente causam problemas

1. Os utilizadores conseguem ver os dados uns dos outros

Este é o problema grave mais comum em aplicações construídas com IA. A página mostra a cada utilizador apenas os seus registos, por isso parece correto. Mas o servidor devolve qualquer registo se alguém alterar o ID na barra de endereços ou num pedido. Como testa sempre como si próprio, nunca o vê.

Como verificar: crie duas contas. Inicie sessão como utilizador A, abra um dos registos de A e anote o endereço. Inicie sessão como utilizador B numa janela privada e cole esse endereço. Deverá ver "não encontrado", nunca os dados de A.

Prompt:

Verifique todos os endpoints do servidor que leem, alteram ou apagam dados de utilizadores. Cada um deve confirmar que o utilizador com sessão iniciada tem permissão para aceder àquele registo específico. Liste os endpoints, explique como cada um faz essa verificação e corrija os que não a fazem.

2. Segredos no sítio errado

Um segredo é tudo o que concede acesso: uma chave de API de um serviço de IA ou de email, a palavra-passe de uma base de dados, a chave secreta de um fornecedor de pagamentos. Se estiver em código que corre no navegador, qualquer pessoa pode abrir as ferramentas de programador e copiá-la. Se for submetida a um repositório público, os bots encontram-na em poucas horas.

Como verificar: pergunte à IA.

Liste todas as chaves de API, tokens e palavras-passe que esta aplicação usa. Para cada uma, diga onde está guardada e se alguma vez é enviada para o navegador. Mova para segredos do lado do servidor qualquer uma que esteja no código ou no frontend.

3. Formulários e endpoints públicos sem limites

Formulários de contacto, registos e funcionalidades de IA são encontrados por bots. Sem limites, recebe spam, contas falsas ou uma fatura elevada de uma API de IA chamada milhares de vezes.

Prompt:

Adicione limites de pedidos ao registo, ao início de sessão, ao formulário de contacto e a todos os endpoints que chamam um serviço de IA. Adicione um campo honeypot aos formulários públicos. Diga-me os limites que escolheu.

4. Confiar no navegador

Tudo o que o navegador decide pode ser alterado pelo utilizador: preços, descontos, respostas de questionários, marcas de "é administrador". As regras que importam têm de ser aplicadas no servidor.

Prompt:

Encontre todos os sítios onde o navegador decide algo que deveria ser decidido pelo servidor: preços, totais, permissões, funções, pontuações. Mova essas verificações para o servidor.

5. Sem forma de voltar atrás

Uma alteração errada, ou um mau ator, pode apagar dados. Sem cópias de segurança e sem forma de reverter, um pequeno erro torna-se permanente. Certifique-se de que a sua ferramenta tem checkpoints para o código e cópias de segurança para a base de dados. Veja como fazer cópias de segurança da base de dados da sua aplicação.

Como tratar os segredos corretamente

Os segredos causam mais danos evitáveis do que qualquer outra coisa, por isso aqui ficam as regras num só lugar:

• Nunca cole uma chave real no chat. As conversas são guardadas, partilhadas e fotografadas. Coloque as chaves nos segredos ou variáveis de ambiente da sua ferramenta. (O que são variáveis de ambiente e segredos.)
• Chame os serviços pagos a partir do servidor. O navegador pede ao seu servidor; o servidor chama o serviço de IA ou de pagamentos com a chave.
• Use chaves separadas para testes e para uso real, para que uma chave de teste divulgada não toque em dinheiro real.
• Defina limites de gastos nos painéis dos fornecedores de IA e de email.
• Renove uma chave imediatamente se suspeitar que foi divulgada. Crie uma nova, atualize o segredo e depois apague a antiga.

Na Mythex, os segredos ficam nas definições do projeto, fora do código, e o agente pode usá-los sem que os valores apareçam no chat. O nosso guia sobre como manter as chaves de API seguras cobre mais fornecedores.

Quanta revisão de código precisa?

Fazer vibe coding significa que não lê todas as linhas. Não tem de o fazer. Mas, em algumas linhas, alguém deve olhar.

• Ferramentas pessoais: nada além das verificações aqui indicadas.
• Aplicações com contas de utilizador: reveja como funcionam o início de sessão e o acesso aos dados. Pode fazê-lo pedindo à IA que explique em linguagem simples e confirmando que a explicação corresponde ao que espera.
• Aplicações com pagamentos ou dados sensíveis: peça a um programador que analise a autenticação, as permissões, o tratamento de pagamentos e tudo o que guarde dados pessoais. São algumas horas do tempo dele, não uma reescrita.

Um prompt útil mesmo sem programador:

Explique, em linguagem simples, como esta aplicação decide quem é um utilizador e o que ele pode ver. Indique os ficheiros. Depois liste o que gostaria que um revisor de segurança analisasse.

O nosso guia sobre como rever código gerado por IA explica o que os revisores procuram, e pode entregá-lo a quem fizer a revisão. Se a sua ferramenta permitir exportar o código ou sincronizar com o GitHub, organizar essa revisão é fácil; na Mythex, ambas as opções fazem parte do plano Pro.

A verificação de 30 minutos antes de publicar

Faça isto antes de partilhar o link com alguém fora do seu círculo.

Acesso (10 minutos)

1. Duas contas, dois navegadores: consegue B abrir os registos de A através do URL? Não deveria.
2. Termine a sessão e visite diretamente o endereço de cada página. As páginas privadas devem enviá-lo para o início de sessão.
3. Como utilizador normal, tente abrir endereços de administração. Devem ser recusados.

Segredos (5 minutos)

1. Pergunte à IA onde está cada chave, usando o prompt acima.
2. Abra a aplicação, veja o código-fonte da página e procure "key", "secret" e "token".

Formulários e abusos (5 minutos)

1. Envie cada formulário vazio, com textos muito longos e duas vezes em rápida sucessão.
2. Confirme que existem limites de pedidos no registo, no início de sessão e em qualquer funcionalidade de IA.

Dados e recuperação (5 minutos)

1. Saiba onde os dados estão guardados e como os restaurar.
2. Confirme que consegue reverter o código para uma versão anterior que funcionasse.

Aspetos legais e básicos (5 minutos)

1. Se recolher dados pessoais, adicione uma política de privacidade e diga o que recolhe. Veja como escrever termos de serviço e uma política de privacidade.
2. Confirme que a aplicação publicada usa HTTPS. A maioria dos construtores, incluindo a Mythex, trata disso por si.

Se tudo passar, está bem preparado para um lançamento inicial. Repita os passos 1 a 5 após qualquer alteração grande ao início de sessão, às funções ou aos dados.

O que as plataformas de vibe coding protegem e o que não protegem

Uma boa plataforma trata de grande parte da infraestrutura: HTTPS, espaços de trabalho isolados, uma base de dados por projeto, armazenamento de segredos, cópias de segurança e reversão. A Mythex dá a cada projeto o seu próprio espaço de trabalho privado e base de dados, mantém os segredos fora do código e guarda um checkpoint após cada alteração bem-sucedida, para que a possa desfazer.

O que nenhuma plataforma consegue fazer é conhecer as regras da sua aplicação. Só você sabe que os clientes não devem ver as faturas uns dos outros, ou que um cupão deve funcionar apenas uma vez. Essas regras têm de estar nos seus prompts e ser confirmadas pelos seus testes.

A resposta curta

O vibe coding é tão seguro quanto as verificações que acrescenta. Para uma ferramenta pessoal, mantenha as chaves fora do código e aproveite. Para qualquer coisa com dados de outras pessoas, faça a verificação de 30 minutos acima antes de cada lançamento e peça a um programador que analise pagamentos e dados sensíveis. Para ver estes riscos em projetos reais, leia os nossos exemplos de vibe coding; para construir com estas verificações desde o início, siga como criar uma aplicação com vibe coding.

Perguntas