Segurança do v0: os 1.790 aplicativos v0 escaneados tiraram A

Você descreveu um aplicativo para o v0, viu ele construir e recebeu de volta um link que termina em vusercontent.net. Funciona, parece pronto, e talvez você já tenha mandado para alguém. Antes que clientes de verdade digitem os dados deles ali, você pesquisou a segurança do v0, e parte do que apareceu foi uma história sobre atacantes usando o v0 para construir páginas de login falsas.

Essa história é sobre o que outras pessoas fazem com a ferramenta. Este artigo é sobre o aplicativo que você fez com ela, e para isso temos uma medição. Entre 12 e 14 de agosto de 2026 rodamos as mesmas nove verificações externas que qualquer pessoa pode rodar de graça na nossa página inicial em 30.998 aplicativos no ar, e 1.790 deles eram aplicativos v0. Todos os 1.790 tiraram A.

Esta é a parte que um ranking entende errado: esse A diz mais sobre o que havia para verificar do que sobre o v0. Lido como ranking, ele faz do v0 o builder mais seguro que medimos. Lido com os seus denominadores, ele descreve frontends sem nada por trás, e deixa de descrever o seu no dia em que você conecta um banco de dados.

O v0 é seguro?

Em tudo o que conseguimos medir sobre o próprio v0, sim. O único achado dele pertence ao domínio de onde o v0 serve o seu aplicativo, e nada mais apareceu em nenhum dos 1.790, em nenhuma das nove verificações. O que isso não consegue dizer é como o seu aplicativo se comporta quando guarda dados, porque quase nenhum destes guardava.

Pense numa prévia do v0 como um gaveteiro num showroom. As gavetas deslizam, as etiquetas estão no lugar, qualquer um que passe pode puxar uma, e todas as gavetas estão vazias. Nossas verificações testaram cada gaveta e não encontraram nada em nenhuma, e esse é um relato correto de um gaveteiro vazio.

O quanto ele está vazio, os números dizem. Só 17 dos 1.790 citavam um projeto do Supabase em algum lugar do código que publicam, e em todos os 17 a nossa verificação de banco de dados não obteve uma resposta que pudesse julgar, então a contagem de tabelas legíveis no v0 é zero de zero. Todos os 1.790 eram servidos de vusercontent.net, que a Vercel descreve no seu pedido à Public Suffix List como o lugar "onde hospedamos o conteúdo enviado pelos usuários" do v0. Um aplicativo que você publica vai para um endereço vercel.app ou para um domínio seu, onde nada o marca como v0 de fora, então esses não estão na contagem. O método e os dados completos estão no relatório.

Então "o v0 é seguro?" são três perguntas:

1. A ferramenta. O que o v0 verifica no código que escreve, e o que ele se recusa a publicar. Essa parte é da Vercel, e está documentada.
2. A prévia. O gaveteiro no showroom, no seu endereço vusercontent.net. Todos os aplicativos que medimos estavam nesta etapa.
3. O aplicativo que você enche. O mesmo código quando guarda os dados dos seus clientes, ou roda num domínio seu. Quase nada do que medimos tinha chegado até aqui.

O que a segurança do v0 cobre antes de você publicar

Três coisas, e a própria documentação do v0 nomeia cada uma delas.

Ele relê o código que escreveu. A página de segurança do v0 diz que todo código gerado "passa por uma análise de segurança antes da execução", e que o v0 "analisa o uso de NEXT_PUBLIC_ e avisa os usuários sobre possíveis riscos de segurança". NEXT_PUBLIC_ é o prefixo que diz ao Next.js, o framework em que o v0 escreve, para colocar um valor no código que todo visitante baixa. O que esse prefixo faz com uma chave tem um artigo próprio.

Ele recusa alguns deploys. Em agosto de 2025 a Vercel escreveu que o v0 tinha bloqueado mais de 17.000 deploys nos 30 dias anteriores só por segredos expostos, e mais de 100.000 deploys inseguros desde o lançamento. São números da Vercel sobre o bloqueio da Vercel, que vale para deploys na Vercel. Parte do nosso zero pode ser obra desse bloqueio. De fora, não dá para saber quanto.

A integração com o Supabase põe o prefixo no lugar certo. Conectada pelo Vercel Marketplace, ela adiciona uma dúzia de variáveis de ambiente, e só duas levam NEXT_PUBLIC_: o endereço do projeto e a chave publicável, as duas feitas para ser públicas. SUPABASE_SECRET_KEY e a senha do banco ficam sem ele, no servidor.

Por que falta cabeçalho de segurança numa prévia do v0

Porque quem os define é o domínio de prévias do v0, todo aplicativo nele recebe a mesma resposta, e de dentro de uma prévia você não consegue mudar isso.

Cabeçalhos de segurança são instruções que um site manda com cada página: use sempre HTTPS, não deixe outro site mostrar esta página dentro da dele, não tente adivinhar que tipo de arquivo é este. Quem serve a página é quem manda. As prévias que abrimos em 3 de outubro de 2026 mandavam um dos cinco que a nossa verificação procura, o que obriga o uso de HTTPS, e nenhum dos outros quatro. Esse é o achado em todos os 1.790 aplicativos v0, e é o único.

O showroom decide as próprias portas e alarmes, e você não consegue refazer a fiação deles para um único gaveteiro do salão. Assim que você publica, o gaveteiro está no seu escritório, e os cabeçalhos são uma configuração no vercel.json ou na sua configuração do Next.js. O que cada cabeçalho faz, e os dois que não custam nada, é outro artigo.

Uma prévia do vusercontent.net é pública?

Trate como pública. Qualquer pessoa com o endereço consegue abrir, e endereços circulam.

Cada uma das 1.790 abriu para nós sem login, e não precisamos adivinhar nenhuma: os endereços vieram de um arquivo público da web que já tinha guardado uma cópia de cada uma. As configurações de compartilhamento do v0 decidem quem pode ver o seu chat: privado por padrão, depois a sua equipe, qualquer um com o link, ou qualquer um na web. A documentação não diz que essas configurações chegam até a prévia.

Então uma prévia é o gaveteiro no showroom. Serve para mostrar o design a alguém e não serve para os documentos de verdade de ninguém. A Vercel colocou vusercontent.net na Public Suffix List em setembro de 2024, o que faz os navegadores tratarem cada prévia como um site separado, então uma prévia não consegue definir cookies para todas as outras. Isso mantém as prévias separadas umas das outras, e não faz nada para manter a sua privada.

Se você está aqui porque alguém mandou um link do vusercontent.net: o domínio é da Vercel, e a página nele foi feita por quem a pediu num prompt. Em 1º de julho de 2025 a Okta relatou atacantes usando o v0 para construir cópias de páginas de login reais, e a Vercel restringiu o acesso às que encontrou. Não digite uma senha num formulário de login num endereço assim a menos que você estivesse esperando por ele.

O que muda quando você conecta o Supabase ao v0

Você começa a encher as gavetas, e as verificações que voltaram vazias no v0 passam a ter algo para verificar.

O v0 adiciona o Supabase com um clique e, nas palavras da própria documentação, "pode gerar e executar SQL. Isso permite criar, atualizar e apagar tabelas". É assim que as suas tabelas nascem. Cada tabela é uma gaveta, e a Row Level Security é a fechadura dela: uma configuração por tabela que decide quais linhas a chave publicável da sua página pode ler. Essa chave foi feita para ser pública, então a fechadura é a única coisa que decide o que um desconhecido recebe.

O Supabase põe essa fechadura por padrão nas tabelas criadas no Table Editor dele, e deixa de fora nas tabelas criadas rodando SQL, que é como o v0 as cria.

Foi aí que caíram os achados graves em todos os outros builders. Dos 3.553 aplicativos Lovable cujo banco conseguimos consultar, 2.017 entregaram linhas a uma requisição sem login, e os números do Lovable são a cara dos resultados de um builder quando já há documentos nas gavetas. Uma fechadura que qualquer chave abre também não é fechadura: uma política que diz using (true) deixa todo mundo passar enquanto o painel mostra a tabela como protegida. A RLS está ligada e a sua tabela continua pública conta a história inteira.

Se os seus dados ficam atrás de rotas que o seu próprio código de servidor responde, a mesma pergunta vale para essas rotas: o que significa um endpoint de API aberto.

O que muda quando você publica ou faz o deploy por conta própria

O gaveteiro sai do showroom para o seu escritório, e as decisões que o domínio do v0 tomava passam a ser suas.

Publicar pelo v0 cria um projeto na Vercel e pergunta três coisas, segundo a documentação de deploys do v0: o nome do projeto, quem pode acessar o aplicativo publicado, e o domínio, um endereço vercel.app ou um seu. Vá devagar na segunda. As opções que você vê dependem do seu plano, e deixar o aplicativo só para a sua equipe ou atrás de uma senha até você ter verificado mantém desconhecidos de fora enquanto você olha.

Três coisas passam para você quando publica:

• Os cabeçalhos. As portas e alarmes do escritório agora quem configura é você.
• As variáveis de ambiente. Elas ficam nas configurações do seu projeto, e é nessa lista que uma chave recebe ou não o prefixo NEXT_PUBLIC_.
• A verificação do seu deploy, se você sair da Vercel. A Vercel descreve o bloqueio dela como algo que barra deploys na Vercel, então o código que você baixa e hospeda em outro lugar sai sem essa verificação.

De um jeito ou de outro, você saiu da amostra que medimos. Um aplicativo v0 no próprio domínio com um banco de dados por trás tem mais em comum com os aplicativos Bolt que medimos do que com estas 1.790 prévias.

Como verificar o seu próprio aplicativo v0

Cinco coisas, e as três primeiras só passam a importar depois que você conectou um banco de dados ou publicou. Use uma janela anônima, para que o seu próprio login não responda por um desconhecido.

1. Leia as suas variáveis de ambiente. No v0 elas ficam no menu do projeto, em Settings, Environment Variables. Tudo que começa com NEXT_PUBLIC_ está no código que todo visitante baixa. O endereço de um projeto e uma chave publicável ficam bem ali. Uma chave que gera cobrança para você, SUPABASE_SECRET_KEY e qualquer coisa que guarde uma senha, nunca. Se alguma delas já levou o prefixo, faça a rotação com o provedor primeiro, porque o valor antigo continua funcionando até você fazer isso.
2. Leia a fechadura de cada tabela. No Supabase, abra Authentication → Policies e percorra a lista. Uma tabela com a Row Level Security desligada é legível por qualquer um que tenha o endereço do seu projeto, e esse endereço está na sua página. Uma política que libera tudo para todos conta como desligada.
3. Escolha quem pode ver quando publicar. Só a sua equipe, ou uma senha, até as duas primeiras estarem feitas.
4. Defina os seus cabeçalhos quando o domínio for seu. Dois deles são uma linha cada.
5. Depois olhe de fora. O nosso escaneamento roda as nove verificações contra o endereço publicado como um desconhecido faria, leva uns 20 segundos e não pede conta: escaneie seu aplicativo de graça.

Um escaneamento de fora não vê o código que o v0 escreveu, nem o chat em que você o escreveu, nem uma tabela que as suas páginas nunca mencionam. As verificações do v0 veem o código por dentro e não veem o que um desconhecido recebe do endereço. Use as do v0 enquanto constrói, olhe de fora depois de publicar e, se as duas discordarem sobre uma tabela ser legível, fique com a resposta de fora, porque é ela que um desconhecido recebe. A versão em linguagem simples para esta plataforma é o seu aplicativo v0 é seguro?.

Para continuar assim depois de publicar

Um A numa prévia descreve uma prévia. No dia em que você conecta um banco de dados ou publica no seu próprio domínio, a sua nota pode mudar, e nada na sua tela avisa que mudou.

O Reeve Monitor roda as nove verificações de novo para você:

• as nove verificações a cada hora, em até três aplicativos
• se o aplicativo está no ar, a cada 60 segundos
• uma mensagem quando um resultado muda, para que uma tabela ou chave nova não espere você olhar
• um relatório mensal do que ele viu

O Monitor custa $12 por mês no preço de tabela, com sete dias grátis antes de cobrar. A página de preços às vezes fica abaixo do número daqui e nunca acima.

Se o seu aplicativo v0 guarda os dados no Supabase, o Reeve Care guarda uma cópia do seu banco do Supabase.

• uma cópia criptografada toda noite, guardada onde o seu projeto não alcança
• cada cópia verificada antes de valer, com a contagem das linhas de cada tabela
• uma restauração com um clique quando você precisar
• os seus arquivos enviados também, assim que você conectar uma credencial de Storage
• tudo o que o Monitor faz

O Care custa $49 por mês no preço de tabela para um aplicativo, com os mesmos sete dias grátis.

A documentação do v0 diz que ele pode apagar tabelas, além de criar, e nenhuma das nove verificações acima traria de volta as linhas de uma delas. O dia em que um agente de IA apagou um banco de dados de produção mostra como isso fica visto de dentro.

O que fazer esta semana

Comece pelas variáveis de ambiente, porque são elas que decidem o que todo visitante baixa. Se você ainda está escolhendo um builder, qual builder de aplicativos com IA é o mais seguro coloca os cinco lado a lado.