A Armadilha da Velocidade no Desenvolvimento com IA

Vamos ser sinceros: todos já fizemos isso. Passamos uma tarde dando prompts no Lovable, Bolt ou Cursor, e na hora do jantar tínhamos um site no ar. Parecia mágica. A plataforma cuidava da hospedagem, o SSL era automático, e nosso projeto paralelo estava subitamente real.

Mas aqui está a verdade incômoda que não sai da minha cabeça: entregar rápido não significa entregar seguro. E como alguém que acompanhou de perto essa revolução do vibe coding, acho que precisamos conversar sobre o que esse pipeline da tarde-ao-ar realmente deixa para trás.

Um estudo recente escaneou 155 aplicações feitas com vibe coding que seus criadores tinham lançado publicamente. Cento e noventa e nove ainda estavam no ar e puderam ser escaneadas. Os resultados? Igual parte encorajador e preocupante — e eles deveriam mudar a forma como pensamos nas listas de verificação pré-lançamento.

A Boa Notícia: Segredos Permaneciam Ocultos

Aqui está o que me surpreendeu positivamente: apenas 1% dos apps escaneados vazaramm chaves secretas reais para o navegador.

Nenhuma chave de API da OpenAI exposta queimando o orçamento de outra pessoa. Nenhuma credencial da AWS flutuando no JavaScript do cliente. Nenhuma chave de produção do Stripe pronta para esvaziar uma conta bancária.

Isso me diz algo importante: as plataformas modernas de codificação com IA melhoraram genuinamente seus padrões. Quando você cria um novo projeto no Bolt ou Replit, a plataforma te orienta a usar edge functions para segredos em vez de despejar tudo no bundle do navegador. Isso é genuinamente um bom design de UX para segurança.

Mas um por cento ainda é um por cento demais. Uma única chave exposta pode significar uma conta de 50 mil dólares da OpenAI, uma conta AWS comprometida, ou uma disputa no Stripe que afunda sua startup antes dela começar. Não seja esse um por cento.

O Problema do Supabase que Ninguém Comenta

Aqui é onde a coisa fica realmente complicada.

Trinta e sete por cento dos apps vivos feitos com vibe coding incluem uma chave anônima do Supabase no código frontend. E antes de você entrar em pânico — isso é realmente esperado. O Supabase foi projetado assim. A chave anônima é feita para ser pública; a segurança dos seus dados deve vir das políticas de Row Level Security (RLS).

Aqui está o problema: RLS é opt-in. Tabelas começam completamente abertas. E quando você está fazendo vibe coding às 23h, correndo para cumprir o prazo de lançamento, é assustadoramente fácil esquecer aquela caixinha de seleção.

Cada tabela com RLS desabilitado — ou pior, uma política preguiçosa com using (true) — é uma porta escancarada para qualquer pessoa com aquela chave anônima pública. Um atacante não precisa hackear nada. Ele só... consulta seu banco de dados, porque você esqueceu de uma configuração.

Não posso enfatizar o suficiente: scanners passivos não conseguem detectar configurações erradas de RLS. O scanner só vê o frontend. A vulnerabilidade mora no seu banco de dados. Você precisa verificar manualmente, tabela por tabela, antes de ir ao ar.

O mesmo conselho vale para o Firebase (que apareceu em 4% dos apps escaneados). Regras de segurança não são opcionais. Elas são todo o modelo de segurança.

Headers de Segurança: A Lista de Tarefas Invisível

Se você nunca pensou em headers de segurança HTTP, você não está sozinho. Noventa e um por cento dos apps escaneados não têm Content-Security-Policy, e 88% podem ser incorporados em iframes em qualquer site (olá, clickjacking).

Estas não são vulnerabilidades exóticas. São passos padrão de hardening que são best practice há anos. O pipeline de vibe coding simplesmente... não inclui eles por padrão.

Aqui está o detalhamento do scan:

• 91% sem Content-Security-Policy
• 88% sem X-Frame-Options / frame-ancestors
• 37% sem X-Content-Type-Options
• 38% sem Referrer-Policy
• 8% sem Strict-Transport-Security
• Apenas 5% tinham todos os headers de segurança configurados

O ponto positivo? As plataformas de hospedagem lidam com HSTS automaticamente, então isso está praticamente coberto. Mas a lacuna de CSP é significativa. Quando um componente escrito por IA renderiza conteúdo gerado pelo usuário ou integra scripts de terceiros, um CSP é sua última linha de defesa. Sem um, ataques XSS não têm onde se esconder.

A Lacuna de Polimento do Lançamento

Aqui está um achado que eu não esperava me importar, mas que me importou completamente: 30% dos apps feitos com vibe coding lançam sem tags Open Graph.

Isso significa que quando alguém compartilha seu produto no X (Twitter), Discord ou LinkedIn, ele aparece como uma URL crua sem imagem de preview, sem título, sem descrição. Só... texto. Em 2024, isso parece amador e mata suas taxas de clique.

Outros deslizes do dia do lançamento encontrados no scan:

• 11% não tinham meta description
• 77% não tinham sitemap.xml
• A nota média de segurança ficou em B-menos (84/100), com apenas 13% alcançando um A

Os apps não eram desastres — eles só precisavam de polimento. A mesma velocidade que te leva ao lançamento é a velocidade que te faz esquecer do <meta property="og:title">.

Minha Checklist de 5 Minutos Pré-Lançamento

Depois de ler essa pesquisa, atualizei minha checklist pessoal de lançamento. Aqui está o que realmente importa antes de você postar aquele thread no Show HN:

1. Caça de segredos no seu bundle

Procure no seu output compilado por sk-, sk_live_, service_role, ghp_. Qualquer coisa que combine deve ser girada imediatamente e movida para uma edge function ou variável de ambiente. Uma chave exposta é o suficiente para causar problemas.

2. Audite cada tabela do Supabase ou Firebase

Abra seu dashboard. Toda tabela pública precisa de RLS habilitado. Toda política precisa ser específica — nunca using (true). Acesso de leitura a uma única tabela mal configurada pode expor todo o seu banco de dados de usuários.

3. Adicione estes headers de segurança

Content-Security-Policy: frame-ancestors 'none'
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin

Comece com Content-Security-Policy-Report-Only se quiser testar sem imposição. Mas implemente.

4. Desabilite source maps de produção

Seus arquivos *.map são ouro para depuração — para você e para atacantes. A maioria das plataformas tem um toggle. Desligue antes de lançar.

5. Adicione seus metadados Open Graph

No mínimo: og:title, og:description, og:image. Seu post de lançamento merece ter uma boa aparência no feed.

6. Gere um sitemap.xml

Seu eu do SEO futuro vai te agradecer. A maioria das plataformas gera isso automaticamente — verifique se a sua fez.

O Quadro Geral

Aqui está minha opinião: vibe coding não é o problema. O problema é a lacuna entre "funciona na minha máquina" e "está pronto para produção". Desenvolvedores tradicionais aprenderam essa lacuna através de anos de deploys dolorosos. Vibe coders estão aprendendo mais rápido — o que é genuinamente bom.

As plataformas estão melhorando. Os padrões estão ficando melhores. Mas até que o hardening de segurança seja tão automático quanto certificados SSL, a responsabilidade fica conosco, construtores, de adicionar aquela checklist de cinco minutos antes de lançar.

A velocidade do vibe coding é um superpoder. Segurança não precisa ser o tributo que você paga por usá-la.