Resumo: auditar frontend vibe-coded antes de subir
- Todos programam, mas: Todo mundo pode programar é slogan de marketing, não controlo de segurança. Lovable, Cursor, Copilot e Replit embutem sem cerimónia chaves de API no frontend, validam a autenticação no navegador e puxam jQuery abaixo de 3.5.0 para o seu build.
- Os deslizes clássicos: Os deslizes clássicos do vibe-coding são segredos hard-coded, autenticação apenas no cliente e bibliotecas desatualizadas com CVEs conhecidas. A cside desofusca e inspeciona cada script de terceiros que chega ao navegador, para que uma surpresa entregue pela IA não se transforme numa vulnerabilidade em produção.
- Não faça merge às cegas: Não faça merge do pull request que adicionou uma tag de script enquanto ninguém conseguir identificá-la e aos seus destinos de rede. A velocidade ganha o sprint, as fugas perdem o trimestre.
Sem tempo? Veja a deteção de agentes de IA da cside. Cobre tudo o que se segue numa única implementação.
Neste Blog:
- Checklist de Vulnerabilidades no Vibe Coding
- Como o Vibe Coding Acelera… os Riscos
- Como Mitigar Exposições do Vibe Coding
"Toda a gente pode programar". É essa a promessa de assistentes de IA como Lovable, Claude Code ou Replit. É verdadeiramente entusiasmante. A nossa equipa usa vibe coding para ajustes de front-end na empresa diariamente. Mas se quer lançar rápido, certifique-se de que o barco não está a meter água.
Lançar rápido + Lançar com fugas = Afundar fundo.
Não devemos confiar cegamente no que está por baixo do capô quando o custo é a segurança dos nossos utilizadores. Os erros ocultos acumulam-se. E quando algo corre mal, corre muito mal. Este blog vai explorar alguns dos riscos comuns e dar-lhe indicações sobre o que corrigir antes de colocar em produção.
Cheat Sheet de Vulnerabilidades no Vibe Coding
| Exposição | Ação do Atacante | Sugestão de Mitigação |
|---|---|---|
| Segredos Hard-Coded As ferramentas de IA podem incorporar segredos hard-coded como chaves de API. |
Ver chaves nas páginas do navegador ou nas DevTools. | Verifique novamente se há segredos hard-coded no JS. Use armazenamento no lado do servidor. |
| Chaves de API e de base de dados diretamente no código do cliente. | Extrair chaves, obter acesso à base de dados ou à API. | Use variáveis de ambiente ou integrações com serviços de vault. |
| Autenticação apenas no lado do cliente O código gerado por IA frequentemente valida logins apenas na interface do navegador, sem verificações no lado do servidor. |
Chamar diretamente as APIs de back-end para contornar a autenticação. Aceder a dados de utilizadores ou alterar permissões. |
Aplique autenticação e autorização no back-end. |
| Bibliotecas e pacotes desatualizados Os LLMs podem usar bibliotecas desatualizadas (por exemplo, Axios, jQuery<3.5.0) com CVEs conhecidas. |
Procurar vulnerabilidades conhecidas em bibliotecas antigas. Explorar usando métodos de ataque de baixo esforço. |
Execute npm audit fix (Node) ou pip-audit (Python) para atualizar os pacotes. |
| Headers de segurança em falta A ausência de CSP, opções X-Frame ou definições de CORS não implementadas ficam visíveis no navegador. |
Explorar lacunas nos headers para aplicar clickjacking ou injeções de script. | Use middleware (helmet.js / talisman / definições do Django) para definir os valores predefinidos. |
O Vibe Coding Acelera… os Riscos.
O código gerado por IA baseia-se em dados de um conjunto de treino que, no momento em que este texto foi escrito, pode estar desatualizado. Além disso, as práticas de programação de onde os LLMs recolhem a sua informação podem já ser, à partida, mal escritas.
Considere também o seguinte: plataformas como Lovable e v0 Vercel adicionam automaticamente scripts de analytics, auxiliares de UI ou telemetria. É assim que pode herdar scripts de terceiros desatualizados que não escolheu e que não controla. Se estes forem comprometidos, você também é.
Mais riscos podem permanecer ocultos. Copilot, Claude e Codex sugerem frequentemente pacotes npm desatualizados. Por vezes são mesmo versões com falhas de segurança conhecidas, listadas em bases de dados de exploits. E o Supabase, frequentemente associado ao vibe coding, inclui uma chave anónima predefinida no código do cliente. Se o RLS não estiver ativado, a chave concede acesso irrestrito e qualquer pessoa pode usá-la para consultar ou modificar a sua base de dados.
E predefinições inseguras como CORS com wildcard, headers CSP em falta ou source maps detalhados são atalhos que originam falhas de segurança em produção.
O Risco Adicional no Lado do Cliente em Projetos Codificados com IA
No lado do servidor, controla o acesso, a visibilidade e a execução do seu código quando este é implementado de forma segura. No lado do cliente, não controla. Tudo no navegador pode ser inspecionado, permitindo que qualquer pessoa veja o seu código do lado do cliente e todos os pedidos de rede efetuados. Isto dá aos agentes maliciosos o sandbox perfeito para ver, editar e modificar o seu código enquanto passam despercebidos, à procura de uma forma de explorar o seu site.
Exposições no Lado do Cliente que Está a Lançar ao Fazer Vibe Coding
Aqui estão algumas exposições comuns que fazem o dia de um agente malicioso:
Segredos hard-coded: Para quickstarts e demonstrações, as ferramentas de IA podem usar segredos hard-coded como chaves de API e de base de dados diretamente no código do cliente. Se não os detetar, eles chegam ao navegador, onde qualquer pessoa pode usá-los e abusar deles nas DevTools ou no separador de rede.
Source maps detalhados: É provável que o Replit, o Supabase ou o Vercel, e scaffolds de IA como Copilot, Claude e Cursor, mantenham os source maps ativados para facilitar a depuração. Se isto passar despercebido em produção, os atacantes podem usar a lógica interna, as rotas e as mensagens de erro para fazer engenharia reversa.
Autenticação apenas no lado do cliente: O código gerado por IA frequentemente só trata da lógica de front-end. Assim, as verificações de autenticação apenas no cliente podem parecer seguras na interface, mas sem verificações de autenticação no lado do servidor, o front-end fica completamente exposto. Um agente malicioso simplesmente não usará a interface — chamará diretamente os endpoints da API de back-end.
Bibliotecas desatualizadas: Os LLMs podem usar bibliotecas desatualizadas com scripts de terceiros, como versões mais antigas do Axios ou jQuery<3.5.0, com CVEs conhecidas. Obviamente, arrisca-se a lançar bugs e vulnerabilidades do passado. Esqueceu-se de sanitizar o seu HTML ou passou-lhe despercebido um innerHTML na pressa do vibe coding? Importar DOM XSS piora ainda mais a situação.
Como Mitigar Exposições do Vibe Coding
Pacotes
Pacotes NPM desatualizados são frequentemente usados em código gerado por IA, o que pode resultar em CVEs conhecidas incluídas no seu projeto desde o início. Usar o comando 'npm audit fix' em ambientes Node JS vai atualizar automaticamente os seus pacotes npm para as versões mais recentes, juntamente com correções de vulnerabilidades atualmente conhecidas.
Para ambientes baseados em Python, como Django e Flask, usar o pacote Python pip-audit fará o mesmo para os pacotes Python instalados no seu ambiente.
Headers de Segurança
Configurações incorretas de headers de segurança, como headers CSP em falta, opções X-Frame em falta ou definições de CORS não implementadas, ficam visíveis no navegador do utilizador quando este visita o seu site.
Quando os projetos são desenvolvidos com vibe coding do início ao fim sem um entendimento claro dos headers de segurança necessários, isso deixa muita margem para que a IA falhe definições que não são consideradas por predefinição, resultando em vulnerabilidades.
O helmet.js pode ser usado em ambientes Node JS para implementar headers de segurança gerais. Uma ferramenta semelhante para ambientes Flask seria o talisman, enquanto o Django exige que consulte a documentação oficial para garantir que essas definições e os seus valores são adicionados corretamente ao ficheiro de configuração do seu projeto.
O mais importante, no entanto, ao definir estas configurações, é garantir que compreende o seu propósito e o que é necessário para o seu site. Deixar que a IA escreva estas definições inteiramente por si pode resultar em configurações muito permissivas que abrem a porta a vulnerabilidades, enquanto usar um pacote para o seu projeto pode ter o efeito oposto e resultar em definições de segurança muito mais rígidas do que o necessário, causando grandes problemas de funcionalidade num ambiente de produção.
O Que os Fornecedores de IA Estão a Fazer para Melhorar a Segurança
Não é que plataformas como Lovable, Replit ou assistentes de IA como o ChatGPT estejam a menosprezar a segurança. A Lovable, por exemplo, acabou de lançar a segunda geração do seu Security Checker. O sistema sinaliza riscos e bloqueia conteúdo malicioso como phishing ou malware. Além disso, normas do setor com certificações SOC 2 Type 2 e ISO 27001:2022 também estão a entrar em vigor. Anunciaram recentemente também uma parceria com a HackerOne, que é a escolha premium como fornecedor de bug bounty.
Para criadores e utilizadores, a segurança já não é apenas uma nota de rodapé. O Replit adicionou predefinições de segurança mais fortes e o Copilot usa scans e Autofix para o GitHub. Outros grandes intervenientes, como a OpenAI, estão a reforçar os controlos com políticas de rede mais rígidas e proteções de nível empresarial.
Perguntas e Respostas: O que Corrigir Antes de Lançar
P: Qual é a forma mais rápida de verificar segredos expostos? R: Use git-secrets/trufflehog para procurar chaves de API antes de fazer o deploy ou verifique-as nas DevTools.
P: Como verificar o CORS rapidamente? A: Nas DevTools, procure por Access-Control-Allow-Origin. Se encontrar '*' com credenciais, especifique as origens permitidas e certifique-se de que as credenciais são tratadas de forma segura.
P: Qual é a forma rápida e fácil de fazer scan das dependências? R: Execute npm audit fix. Para um scan completo, existe o Socket.dev para integrar no seu pipeline de CI/CD.
P: Regra geral para código sugerido por IA? R: Não confie cegamente no código gerado por IA. Faça scan de vulnerabilidades sempre. Valide sempre, sempre o código, fixe as dependências em versões específicas e bloqueie-as para evitar alterações.
