A maioria dos desenvolvedores "vibe" ainda está lançando aplicativos com segurança zero. Eles focam em funcionalidades, design e velocidade de lançamento. A parte chata parece lição de casa.
Alguns estão pagando por isso. Contas de US$ 200 no Supabase da noite para o dia. Enxurrada de spam no primeiro dia. Alguns poucos estão recebendo cartas de cessação e desistência que não viram chegar.
E depois há um pequeno grupo que silenciosamente executa uma lista de verificação de 30 minutos antes de cada lançamento. O tipo de coisa que não aparece na sua demonstração, mas determina se seu aplicativo sobrevive aos seus primeiros usuários reais.
Compartilhei uma versão rápida disso como um post. Teve mais de 900.000 visualizações, e as respostas e DMs pediram 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 você paga por isso 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 combina com tudo o 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 lista de verificação pré-lançamento no Reddit que viralizou na comunidade de codificação "vibe". Era concisa. Cinco categorias. Prompts reais que você pode copiar para o Claude ou Cursor.
Ele acertou a base.
→ 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 a OWASP, não apenas com cabeçalhos de segurança
→ Verifique vazamentos de dados no frontend e rotas de API
→ Nunca envie chaves de API para o navegador
Mas depois de auditar dezenas de aplicativos "vibe codeados" antes de cotar 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 base abaixo. Ambos importam. Se você fizer apenas um, ainda estará exposto.
O Problema com a Abordagem da Maioria dos Desenvolvedores "Vibe" à 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 interface parece polida. A demonstração funciona perfeitamente. Nada disso protege você quando alguém abre o DevTools e lê todo o seu banco de dados.
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 pacotes frontend. Sem limites de taxa em endpoints caros. Mensagens de erro que mapeiam todo o esquema para qualquer invasor que as acione.
A correção não é paranóia.
A correção é uma lista de verificação de 30 minutos que você executa antes de cada lançamento. Cinco categorias. A mesma que executamos na agência. A mesma que vou mostrar para você.
Seção 1: Proteja a Si Mesmo, Não Apenas Seu Aplicativo
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 desenvolvedores "vibe" 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 gratuitamente 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 os 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 é perfeito. Apenas não é imprudente.
Este é o trabalho mais barato de 10 minutos que você fará em todo o ano 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 é mais importante agora.
O terreno legal sob aplicativos construídos por IA mudou este ano, e a maioria dos construtores ainda não se atualizou.
→ A Suprema Corte manteve a decisão de autoria humana. Código escrito puramente por IA não pode ser protegido por direitos autorais nos EUA. Se um concorrente clonar seu aplicativo construído por IA linha por linha, você pode não ter base legal para impedi-los.
→ 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 US$ 1,5 bilhão, e recebeu aprovação judicial final esta semana. Os advogados não estão chegando. Eles já estão aqui.
Nada disso significa parar de construir. Significa parar de lançar no escuro. O resto desta lista de verificação é como fazer isso.
Seção 2: Bloqueie Seu Banco de Dados
Esta é a seção em que passamos mais tempo quando auditamos projetos recebidos. Quase todo aplicativo "vibe codeado" 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 pessoa 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á para o painel do Supabase. Clique em Autenticação, depois em Políticas. Se você vir zero políticas, seu aplicativo 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, basta pedir 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 aplicativo seguro e uma violação de dados prestes a acontecer.
Validação no lado do servidor em cada formulário.
Zod no cliente não é segurança. É experiência do usuário.
Atacantes desabilitam o JavaScript, abrem o Postman e enviam o que quiserem diretamente para sua API. Se sua única validação está 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.
Este é o básico. 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 invasor 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 rastreamentos de pilha em produção. Segurança operacional básica. A maioria dos aplicativos falha nisso no primeiro dia.
Mensagens ruins entregam seu esquema aos invasores. 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. Pronto.
Os aplicativos quebram quando as coisas dão errado. É exatamente aí que os invasores sondam primeiro.
Aqui está o teste de caso de falha de 4 pontos exato 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. Isso revela se o e-mail está no sistema?
→ Clique no link de verificação de e-mail duas vezes. Isso quebra o fluxo ou lida com isso graciosamente?
→ Cadastre-se com um e-mail que já está registrado. Isso vaza 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 bases de código. Desenvolvedores "vibe" com interfaces 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 aplicativo como um especialista em segurança e certifique-se de que tenho
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 aplicativo em relação aos padrões OWASP e destaque vulnerabilidades.
É aqui que injeção de SQL, XSS e problemas de autenticação são realmente detectados.
Prompt 3. Auditoria de vazamento de dados.
Verifique meu aplicativo em busca de qualquer vazamento de credenciais ou dados confidenciais em
rotas de frontend ou API.
Código gerado por IA vaza dados em 3 lugares quase sempre. Valores .env acabando em código frontend. Respostas de 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 frontend ou em chamadas de rede.
Se sua chave está no navegador, presuma que já foi roubada. Este único bug já drenou projetos indie inteiros em um único fim de semana.
Aprofundando-se em Chaves de API.
Esse prompt pega os casos óbvios. Aqui está a regra que executamos em todos os projetos além disso.
Chaves públicas podem ficar no frontend. Chaves anon 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 de Função Edge do Supabase ou variáveis de ambiente do Vercel. Nunca as confirme no controle de versão. Nunca as cole em seu código 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 em busca de chaves em minutos.
Dois minutos para saber se seus cabeçalhos de segurança estão fazendo algo.
Seção 5: Proteja Sua Infraestrutura
Esta é a seção que protege sua carteira, não apenas seus dados.
Limites de taxa em cada endpoint.
Esta é a maneira mais rápida de um aplicativo "vibe codeado" 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 conta do Supabase saltar de US$ 20 para US$ 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 cada 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 em 50% do seu limite diário para que você pegue um pico antes que ele atinja você pela manhã
Para Funções Edge 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 cada formulário público.
Formulários de contato, páginas de cadastro, listas de espera. Sem CAPTCHA, bots inundam você no primeiro dia. Já vimos formulários de contato coletarem 500 envios de spam em uma hora em aplicativos sem proteção.
Cloudflare Turnstile é gratuito e focado em privacidade. A integração leva 10 minutos.
Restrições CORS em 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 conta 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 Claude Code.
Está em beta, lançado em 22 de julho, e não é um único prompt. É um scanner de vulnerabilidades multiagente que é executado diretamente no seu terminal. Instale-o dentro de uma sessão do Claude Code:
/plugin install claude-security@claude-plugins-official depois /reload-plugins. Isso lhe 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 depois 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, então você não está lidando com falsos positivos
→ O relatório fornece gravidade, ID CWE e o arquivo e linha exatos, e pode transformar descobertas em arquivos de patch que você revisa e aplica você mesmo
→ O modelo por trás dele já encontrou mais de 500 vulnerabilidades de alta gravidade anteriormente desconhecidas em bases de código de código aberto
Você precisa de um plano Claude Code pago (v2.1.154 ou mais novo), e as varreduras usam os tokens do seu plano.
Cursor e construtores visuais como 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 sua pilha tiver.
Corrija tudo o que eles sinalizarem. Não lance com avisos. Não diga a si mesmo que corrigirá depois. A dívida de segurança se acumula mais rápido do que a dívida de funcionalidades.
Trate esta varredura como o portão final antes da implantação. Os prompts manuais pegam o que o scanner perde. O scanner pega o que você esquece de perguntar. Agora que a Anthropic construiu um real no Claude Code, não há desculpa para pular.
Quando Usar Esta Lista de Verificação
Esta lista de verificação é construída para os 80% dos construtores que lançam MVPs, SaaS, ferramentas de IA ou qualquer coisa com dados de usuário.
Use-a quando.
→ Você está lançando qualquer aplicativo que coleta dados do usuário, mesmo um e-mail
→ Você está executando no Supabase, Firebase ou qualquer backend com acesso a banco de dados
→ Você está chamando APIs pagas (OpenAI, Anthropic, Stripe) de sua base de código
→ Você está prestes a compartilhar seu aplicativo publicamente pela primeira vez
Introduza-a gradualmente quando.
→ Você está lançando ferramentas internas usadas apenas por sua própria equipe protegidas por 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 do usuário ainda
Para a maioria dos desenvolvedores "vibe" lançando algo real, cada item desta lista se aplica. Pular qualquer um deles é assumir um passivo que você não precisa.
O Que Observar
Algumas bandeiras honestas antes de tratar isso como a palavra final.
Esta lista de verificação leva você a uma 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 de IA e scanners 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 sofisticados de injeção. 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 apenas 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 codificação "vibe" está amadurecendo rapidamente. 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 custarão 30 dias de apagões de incêndio quando algo quebrar. Vimos isso acontecer em várias 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 lista de verificação como implantação. 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 desenvolvedores "vibe" 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 lista de verificação.
Execute-a antes de cada lançamento. Torne-a parte do seu fluxo de trabalho. Trate-a como teste ou implantação.
Porque os aplicativos que sobrevivem em 2026 não são apenas os que lançam rápido. Eles 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
→ Desenvolvedores "vibe" estão sendo processados, multados e drenados. A maioria ainda não percebeu.
→ Novo em 2026: Código apenas de IA não pode ser protegido por direitos autorais nos EUA, contaminação por GPL pode forçá-lo a abrir todo o seu aplicativo, e o maior acordo de direitos autorais de IA da história (US$ 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 manipulação suspeita.
→ Passo 2. Bloqueie seu banco de dados. RLS no Supabase, validação no lado do servidor em cada 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 de Função Edge do Supabase ou variáveis de env do Vercel. Se expostas, regenere imediatamente.
→ Passo 5. Proteja sua infraestrutura. Limite de taxa em cada endpoint. Defina limites rígidos em APIs pagas. CAPTCHA em formulários públicos. Restrições CORS em 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 Claude Code pagos.
→ Isso leva 30 minutos. Execute antes de cada lançamento.
→ A lacuna entre construtores que executam isso e construtores que pulam vai aumentar rapidamente 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.
Bora.
