A maioria dos vibe coders ainda está lançando apps com segurança zero. Eles focam em funcionalidades, design e lançar rápido. A parte chata parece lição de casa.
Alguns estão pagando por isso. Faturas de $200 do Supabase da noite para o dia. Enxurrada de spam no primeiro dia. Alguns estão recebendo cartas de cessação e desistência que não esperavam.
E há um pequeno grupo que silenciosamente executa uma checklist de 30 minutos antes de cada lançamento. O tipo de coisa que não aparece na sua demo, mas determina se seu app sobrevive aos primeiros usuários reais.
Compartilhei uma versão rápida disso como um post. Ele teve mais de 900.000 visualizações, e as respostas e DMs pediam todos a mesma coisa. O mergulho profundo completo. O contexto de agência. As partes que tive que cortar para caber nos limites de caracteres. Então, muitos de vocês pediram, e aqui está, agora atualizado para onde as coisas realmente estão em 2026.
Construí mais de 60 MVPs na agência em quase 2 anos. Lancei produtos em 21 dias que foram direto para produção. E aprendi que segurança não é algo que você adiciona depois. É algo que você incorpora antes do lançamento, ou paga com apagões de incêndio, reembolsos e danos à reputação.
Este artigo é a versão completa. Começa com o que um desenvolvedor com mais de 20 anos compartilhou no Reddit, depois empilha com tudo que executamos em cada projeto na agência antes de deixarmos algo ir ao ar.
Aqui está a análise completa.
O que o Post do Reddit Acertou (E o Que Perdeu)
Um desenvolvedor com mais de 20 anos compartilhou recentemente uma checklist de pré-lançamento no Reddit que viralizou na comunidade de vibe coding. Era concisa. Cinco categorias. Prompts reais que você pode copiar para o Claude ou Cursor.
Ele acertou a fundação.
→ Proteja-se legalmente antes de coletar um único e-mail
→ Use IA para auditar sua própria postura de segurança em 2 minutos
→ Alinhe-se com OWASP, não apenas com cabeçalhos de segurança
→ Verifique vazamentos de dados no frontend e nas rotas da API
→ Nunca envie chaves de API para o navegador
Mas depois de auditar dezenas de apps feitos com vibe coding antes de orçar reconstruções para clientes, há uma camada abaixo que quase todo construtor perde.
O post do Reddit cobriu a superfície. Este artigo cobre a fundação por baixo. Ambos importam. Se você fizer apenas um, ainda estará exposto.
O Problema com a Abordagem da Maioria dos Vibe Coders à Segurança
A maioria dos construtores trata a segurança como um recurso que adicionarão na versão 2.
Não é um recurso. É o piso.
A IA permite que você lance um produto em um fim de semana. Essa mesma velocidade permite que você lance um passivo em um fim de semana. O código parece limpo. A UI parece polida. A demo funciona perfeitamente. Nada disso te protege quando alguém abre o DevTools e lê seu banco de dados inteiro.
Quando fundadores vêm até nós na agência pedindo para reconstruir um MVP quebrado, as mesmas cinco categorias de falha aparecem quase sempre. Bancos de dados abertos. Fluxos de autenticação que vazam informações. Chaves de API em bundles do frontend. Sem limites de taxa em endpoints caros. Mensagens de erro que mapeiam o esquema inteiro para qualquer atacante que as acione.
A solução não é paranoia.
A solução é uma checklist de 30 minutos que você executa antes de cada lançamento. Cinco categorias. A mesma que executamos na agência. A mesma que vou te guiar agora.
Seção 1: Proteja a Si Mesmo, Não Apenas Seu App
No momento em que você coleta dados do usuário, você está em território legal. GDPR. CCPA. Termos de serviço da plataforma.
A maioria dos vibe coders não pensa nisso até que seja tarde demais.
Três mínimos.
→ Uma política de privacidade real, mesmo que gerada. Termly e PrivacyPolicies.com fazem isso de graça em menos de 5 minutos.
→ Saiba exatamente onde seus dados de usuário residem. Região do Supabase, região do Vercel, quaisquer serviços de terceiros que toquem nos dados.
→ Nada suspeito. Sem vender dados de usuário. Sem exportá-los para seu e-mail pessoal. Sem manter senhas em texto simples.
Não precisa ser perfeito. Só não ser imprudente.
Este é o trabalho mais barato de 10 minutos que você fará no ano inteiro e é a diferença entre um lançamento normal e receber um e-mail de cessação e desistência na segunda semana.
O que mudou em 2026, e por que esta seção importa mais agora.
O terreno legal sob apps construídos por IA mudou este ano, e a maioria dos construtores ainda não se atualizou.
→ A Suprema Corte manteve a decisão sobre autoria humana. Código escrito puramente por IA não pode ser protegido por direitos autorais nos EUA. Se um concorrente clonar seu app feito por IA linha por linha, você pode não ter base legal para impedi-lo.
→ Se sua IA puxar silenciosamente código de código aberto sob uma licença como GPL, você pode ser forçado a abrir todo o seu código-fonte, ou enfrentar uma reivindicação de violação. Você recebe toda a responsabilidade e nenhuma proteção.
→ O maior caso de direitos autorais de IA até agora terminou em um acordo de $1,5 bilhão, e recebeu aprovação judicial final esta semana. Os advogados não estão vindo. Eles já estão aqui.
Nada disso significa parar de construir. Significa parar de lançar às cegas. O resto desta checklist é como fazer isso.
Seção 2: Bloqueie Seu Banco de Dados
Esta é a seção na qual passamos mais tempo quando auditamos projetos recebidos. Quase todo app de vibe coding que já abrimos falha em pelo menos uma das três verificações abaixo.
Segurança em Nível de Linha no Supabase.
Sem RLS, qualquer um pode abrir o DevTools do navegador, executar uma consulta e ler todo o seu banco de dados. Não é hackear. Não é explorar. É apenas abrir o console e digitar um comando.
Vá ao seu painel do Supabase. Clique em Autenticação, depois em Políticas. Se você vir zero políticas, seu app está nu.
A correção é simples. Adicione políticas que restrinjam quem pode ler, inserir, atualizar ou excluir linhas com base no usuário autenticado. Se você estiver usando Lovable ou Bolt, apenas peça ao agente para ativar o RLS e escrever políticas para suas tabelas. Ele gerará o SQL automaticamente.
5 minutos. A diferença entre um app seguro e uma violação de dados prestes a acontecer.
Validação no lado do servidor em todo formulário.
Zod no cliente não é segurança. É UX.
Atacantes desabilitam o JavaScript, abrem o Postman e enviam o que quiserem diretamente para sua API. Se sua única validação é no frontend, eles podem enviar dados malformados, tentativas de injeção de SQL ou scripts. Se seu formulário escreve no banco de dados, VALIDE-O NOVAMENTE no servidor. Verifique tipos de dados. Verifique limites de comprimento. Sanitize entradas.
Esta é a base. Não é opcional.
Mensagens de erro que não vazam dados.
Mensagem de erro ruim. "SELECT * FROM users WHERE email falhou."
Isso diz a um atacante seus nomes de tabela, nomes de coluna e lógica de consulta.
Mensagem de erro boa. "Usuário não encontrado."
Registre erros completos no lado do servidor com contexto. Mostre mensagens genéricas aos usuários. Nunca exponha stack traces em produção. Segurança operacional básica. A maioria dos apps falha nisso no primeiro dia.
Mensagens ruins entregam seu esquema para atacantes. Mensagens boas não revelam nada.
Um prompt. A maioria das suas vulnerabilidades OWASP sinalizadas em 30 segundos.
Seção 3: Teste os Casos de Falha na Autenticação
A maioria dos desenvolvedores testa apenas o caminho feliz. Cadastre-se com um e-mail válido. Faça login. Considere pronto.
Os apps quebram quando as coisas dão errado. É exatamente aí que os atacantes sondam primeiro.
Aqui está o teste exato de 4 pontos de caso de falha que executamos antes de aprovar qualquer projeto.
→ Faça login com a senha errada 5 vezes seguidas. A conta é bloqueada? Mostra um erro genérico ou confirma que o e-mail existe?
→ Redefina a senha para um e-mail que não existe. Revela se o e-mail está no sistema?
→ Clique no link de verificação de e-mail duas vezes. Quebra o fluxo ou lida com isso de forma elegante?
→ Cadastre-se com um e-mail que já está registrado. Vaza a informação de que o usuário já existe?
10 minutos de teste. Pega 80% das vulnerabilidades de autenticação antes que elas entrem no ar.
Executamos este teste exato em todas as auditorias recebidas que fizemos este ano. Ele pegou problemas em aproximadamente 7 de cada 10 codebases. Vibe coders com UIs bonitas perderam isso todas as vezes.
Seção 4: Os 4 Prompts de IA que Você Executa Antes de Cada Lançamento
Esta é a parte que o post do Reddit acertou. Esses quatro prompts cobrem 80% da auditoria de segurança de superfície e levam cerca de 8 minutos no total.
Você os executa dentro do Claude Code, Cursor, ou qualquer agente com o qual você constrói. Salve-os. Torne-os parte do seu ritual de lançamento.
Prompt 1. Postura de segurança básica.
Revise meu app como um especialista em segurança e garanta que eu tenha
cabeçalhos de segurança fortes e uma postura de segurança básica sólida.
2 minutos. Corrige as lacunas óbvias. Apenas cabeçalhos não são suficientes, mas são o piso.
Prompt 2. Verificação de padrões OWASP.
Revise meu app contra os padrões OWASP e destaque vulnerabilidades.
É aqui que injeção de SQL, XSS e problemas de autenticação são realmente pegos.
Prompt 3. Auditoria de vazamento de dados.
Verifique meu app em busca de qualquer vazamento de credenciais ou dados sensíveis em
rotas do frontend ou da API.
Código gerado por IA vaza dados em 3 lugares quase sempre. Valores .env que acabam no código do frontend. Respostas da API retornando muitos dados. Segredos aparecendo em logs.
Prompt 4. Verificação de exposição de chave de API.
Garanta que nenhuma chave de API esteja exposta no código do frontend ou em chamadas de rede.
Se sua chave está no navegador, assuma que já foi roubada. Este único bug já drenou projetos indie inteiros em um único fim de semana.
Aprofundando em Chaves de API.
Esse prompt pega os casos óbvios. Aqui está a regra que executamos em todo projeto além disso.
Chaves públicas podem ficar no frontend. Chaves anônimas do Supabase, chaves publicáveis do Stripe, qualquer coisa explicitamente marcada como pública. Elas são projetadas para serem expostas.
Chaves secretas devem ficar no lado do servidor. Chaves de função de serviço, chaves secretas do Stripe, chaves da OpenAI, qualquer coisa sem um prefixo "publicável". Armazene-as em Segredos da Função de Borda do Supabase ou variáveis de ambiente do Vercel. Nunca as envie para o controle de versão. Nunca as cole no seu código do frontend.
Se você acha que uma chave pode ter sido exposta, regenere-a imediatamente. Não espere. Não espere que ninguém a encontrou. Repositórios públicos do GitHub são varridos por chaves em minutos.
Dois minutos para saber se seus cabeçalhos de segurança estão fazendo alguma coisa.
Seção 5: Proteja Sua Infraestrutura
Esta é a seção que protege sua carteira, não apenas seus dados.
Limites de taxa em todo endpoint.
Esta é a maneira mais rápida de um app de vibe coding esvaziar sua carteira. Sem limites de taxa, alguém pode enviar spam para sua API 10.000 vezes em um minuto. Talvez forçando um login. Talvez raspando seu banco de dados. Talvez apenas sendo malicioso.
Eu pessoalmente vi uma fatura do Supabase saltar de $20 para $200 em um único dia em um projeto paralelo porque um endpoint não tinha limite de taxa. Acontece rápido.
Três mínimos.
→ Limite de taxa em todo endpoint que atinge uma API paga (OpenAI, Anthropic, Stripe, Resend)
→ Defina limites diários rígidos nos painéis da OpenAI e Anthropic
→ Configure alertas a 50% do seu limite diário para que você pegue um pico antes que ele te atinja pela manhã
Para Funções de Borda do Supabase, Upstash é a solução de limite de taxa mais fácil. 100 requisições por minuto por IP para endpoints públicos, 1.000 por minuto para usuários autenticados é uma linha de base sensata.
CAPTCHA em todo formulário público.
Formulários de contato, páginas de cadastro, listas de espera. Sem CAPTCHA, bots te inundam no primeiro dia. Vimos formulários de contato coletarem 500 envios de spam em uma hora em apps sem proteção.
Cloudflare Turnstile é gratuito e focado em privacidade. A integração leva 10 minutos.
Restrições CORS na sua API.
Por padrão, muitos frameworks permitem requisições de API de qualquer lugar. Bom para desenvolvimento local. Desastre em produção.
Especifique exatamente quais domínios podem acessar sua API. Permita seu domínio de produção. Permita localhost para testes. Bloqueie todo o resto. 2 minutos. Previne falsificação de requisição entre sites e acesso não autorizado à API.
Limites rígidos e alertas. A configuração de 3 minutos que salva sua fatura mensal.
Execute a Verificação de Segurança Integrada por Último
Os 4 prompts na Seção 4 são manuais. Você os cola e lê o que volta. Desde 3 dias atrás, você tem algo melhor para o portão final.
A Anthropic acabou de lançar um plugin de Segurança Claude para o Claude Code.
Está em beta, lançado em 22 de julho, e não é um único prompt. É um scanner de vulnerabilidades multiagente que roda diretamente no seu terminal. Instale-o dentro de uma sessão do Claude Code:
/plugin install claude-security@claude-plugins-official e depois /reload-plugins. Isso te dá um comando, /claude-security.
O que o torna diferente de colar um prompt.
→ Uma equipe de agentes mapeia sua arquitetura, constrói um modelo de ameaça e então caça em 4 categorias: injeção, autenticação e acesso, memória, e criptografia e segredos
→ Cada descoberta tem que sobreviver a um painel adversarial de 3 agentes antes de chegar ao seu relatório, para que você não esteja navegando por falsos positivos
→ O relatório te dá gravidade, ID CWE, e o arquivo e linha exatos, e pode transformar descobertas em arquivos de patch que você mesmo revisa e aplica
→ O modelo por trás dele já encontrou mais de 500 vulnerabilidades de alta gravidade anteriormente desconhecidas em codebases de código aberto
Você precisa de um plano pago do Claude Code (v2.1.154 ou mais novo), e as varreduras usam os tokens do seu plano.
O Cursor e construtores visuais como o Lovable também enviam seus próprios scanners que sinalizam configurações incorretas de RLS, segredos expostos, dependências vulneráveis e padrões inseguros. Execute o que seu stack tiver.
Corrija tudo que eles sinalizarem. Não lance com avisos. Não diga a si mesmo que vai consertar depois. A dívida de segurança se acumula mais rápido que a dívida de funcionalidades.
Trate esta varredura como o portão final antes do deploy. Os prompts manuais pegam o que o scanner perde. O scanner pega o que você esquece de perguntar. Agora que a Anthropic construiu um de verdade no Claude Code, não há desculpa para pular.
Quando Usar Esta Checklist
Esta checklist é construída para os 80% dos construtores que estão lançando MVPs, SaaS, ferramentas de IA, ou qualquer coisa com dados de usuário.
Use-a quando.
→ Você está lançando qualquer app que coleta dados de usuário, mesmo um e-mail
→ Você está rodando no Supabase, Firebase, ou qualquer backend com acesso a banco de dados
→ Você está chamando APIs pagas (OpenAI, Anthropic, Stripe) do seu código
→ Você está prestes a compartilhar seu app publicamente pela primeira vez
Introduza-a gradualmente quando.
→ Você está lançando ferramentas internas usadas apenas por sua própria equipe atrás de autenticação
→ Você está trabalhando com uma equipe de segurança que já executa uma auditoria mais abrangente
→ Você está em modo de exploração pré-MVP e não está coletando nenhum dado de usuário ainda
Para a maioria dos vibe coders lançando algo real, cada item desta lista se aplica. Pular qualquer um deles é assumir uma responsabilidade que você não precisa.
O que Observar
Alguns avisos honestos antes de tratar isso como a palavra final.
Esta checklist te leva a uma linha de base confiável, não a conformidade de nível empresarial. Se você está armazenando dados de saúde, dados financeiros, ou qualquer coisa regulamentada, você precisa de uma auditoria de segurança real além disso.
Prompts e scanners de IA pegam problemas de nível de superfície. Eles não pegam vulnerabilidades de lógica de negócios, bugs complexos de estado de autenticação, ou ataques de injeção sofisticados. Trate-os como o piso, não o teto.
A dívida de segurança se acumula. Quanto mais você espera, mais dolorosa a limpeza. Execute isso antes de cada lançamento, não uma vez no início.
Políticas RLS são fáceis de escrever incorretamente. Teste-as tentando acessar dados como um usuário diferente. Apenas ativar o RLS sem testar é pior do que não tê-lo, porque cria falsa confiança.
O que Isso Realmente Significa
Aqui está minha opinião honesta.
A economia de vibe coding está amadurecendo rápido. Um ano atrás, você podia lançar qualquer coisa e ninguém se importava. Agora as plataformas estão aplicando políticas de segurança. Os usuários esperam isso. Os investidores estão verificando isso. Os tribunais traçaram linhas reais este ano, e os advogados começaram a aparecer.
Os 30 minutos que você pula antes do lançamento vão te custar 30 dias de apagões de incêndio quando algo quebrar. Vimos isso acontecer em múltiplas auditorias recebidas este ano, onde fundadores vieram até nós pedindo uma reconstrução depois que sua primeira versão começou a vazar dados ou queimar dinheiro.
Na agência, tratamos esta checklist como deployment. Não é opcional. É parte do lançamento. E com a Anthropic agora incorporando um scanner de segurança diretamente no Claude Code, a lacuna entre construtores que executam isso e vibe coders que pulam vai aumentar ainda mais rápido.
Você não precisa ser paranóico. Você não precisa de segurança de nível empresarial no primeiro dia. Você só precisa desta checklist.
Execute-a antes de cada lançamento. Torne-a parte do seu fluxo de trabalho. Trate-a como teste ou deployment.
Porque os apps que sobrevivem em 2026 não são apenas os que lançam rápido. São os que lançam rápido e não quebram quando usuários reais aparecem.
2026 vai ser INJUSTO para construtores que tratam a segurança como um fluxo de trabalho em vez de um pensamento posterior.
TLDR
→ Vibe coders estão sendo processados, multados e drenados. A maioria ainda não percebeu.
→ Novo em 2026: Código feito apenas por IA não pode ser protegido por direitos autorais nos EUA, contaminação por GPL pode forçá-lo a abrir todo o seu app, e o maior acordo de direitos autorais de IA da história ($1,5B) acaba de receber aprovação judicial final. Proteja-se primeiro.
→ Passo 1. Proteja-se legalmente. Política de privacidade, localização dos dados, sem manuseio suspeito.
→ Passo 2. Bloqueie seu banco de dados. RLS no Supabase, validação no lado do servidor em todo formulário, mensagens de erro que não vazam dados.
→ Passo 3. Teste os casos de falha na autenticação. Senha errada 5 vezes. Redefinição de senha para e-mail falso. Link de verificação clicado duas vezes. Cadastro com e-mail existente.
→ Passo 4. Execute os 4 prompts de segurança de IA. Postura de segurança. OWASP. Vazamentos de dados. Exposição de chave de API.
→ Bloqueie variáveis de ambiente. Chaves públicas podem viver no frontend. Chaves secretas vão para Segredos da Função de Borda do Supabase ou variáveis de env do Vercel. Se expostas, regenere imediatamente.
→ Passo 5. Proteja sua infraestrutura. Limite de taxa em todo endpoint. Defina limites rígidos em APIs pagas. CAPTCHA em formulários públicos. Restrições CORS na sua API.
→ Execute um scanner real como seu portão final. O novo plugin de Segurança Claude da Anthropic executa uma varredura multiagente diretamente no seu terminal. Beta, planos pagos do Claude Code.
→ Isso leva 30 minutos. Execute antes de cada lançamento.
→ A lacuna entre construtores que executam isso e construtores que pulam vai aumentar rápido em 2026.
Post completo do Reddit que desencadeou isso. https://www.reddit.com/r/vibecoding/comments/1sthzcj/if_youre_about_to_launch_a_vibe_coded_app_read/
Tire um print disso. Execute antes de cada lançamento.
Vamos nessa.
