Segurança para a tua app v0

"Segurança no v0" são duas coisas que convém separar. A primeira é o projeto do v0: quem pode ver os teus chats, onde vivem as variáveis de ambiente, o que acrescentam as integrações e para onde é feito o deploy. A segunda é o código que o v0 gera: interfaces Next.js muito bem acabadas que, por desenho, se concentram no que se vê e deixam para depois o que não se vê, que é precisamente a autenticação, a validação e os cabeçalhos. Este guia cobre as duas, com um bloco de instruções para o projeto, um prompt de revisão antes do deploy e as verificações de fora. O modelo do que corre no servidor e do que chega ao navegador está no guia de Next.js.

Parte 1: proteger o teu projeto do v0

Chats públicos e privados

Um chat do v0 pode ser partilhado por link ou publicado na comunidade, e em ambos os casos mostra o código completo e o histórico de prompts, incluindo qualquer chave que tenhas colado na conversa e os nomes das tuas variáveis de ambiente. Revê a visibilidade de cada chat antes de o partilhar, e assume que tudo o que escreveste num chat público já foi lido por alguém.

Variáveis de ambiente e integrações

O v0 tem um painel de variáveis de ambiente por projeto que é usado na pré-visualização e sincronizado com a Vercel no deploy. Esse é o único sítio para as chaves: nunca o chat, nunca um ficheiro do código. As integrações (Supabase, Neon, Upstash, Blob e as restantes do marketplace da Vercel) acrescentam lá as suas variáveis automaticamente; as que começam por NEXT_PUBLIC_ chegam ao navegador e as restantes só ao servidor. Se uma chave secreta tem esse prefixo, está exposta mesmo que a tenhas posto no painel.

Pré-visualização e deploy

A pré-visualização dentro do v0 executa a tua app com as tuas variáveis reais. O deploy vai para a Vercel, com tudo o que isso implica: pré-visualizações públicas por defeito, variáveis por ambiente, firewall e proteção de deploys. O guia da Vercel repassa isso; a primeira coisa a ativar é o Deployment Protection.

Se ligares uma base de dados

Com Supabase, Neon ou qualquer Postgres, as tabelas que o v0 cria nascem sem políticas de acesso e com o esquema que o modelo imaginou. Se for Supabase, o guia do Supabase tem três consultas SQL para auditar num minuto; com outras bases de dados, o acesso é controlado pelo teu código de servidor e aplicam-se as regras da parte 2.

Parte 2: as falhas que o v0 mete no teu código

• Sem autenticação. O v0 constrói o painel, a tabela e os botões; o login chega "no prompt seguinte" ou nunca. Uma app publicada com um dashboard sem sessão é inteiramente pública.
• Dados de exemplo que ficam. Utilizadores fictícios, chaves de teste e um admin / admin num ficheiro de dados que acaba em produção.
• fetch a partir do componente com a chave lá dentro. A chamada à API externa vai no componente de cliente, com a chave à vista nas ferramentas do navegador.
• Server Actions e Route Handlers sem verificar a sessão. O botão esconde-se se não fores administrador, mas a ação continua a ser um endpoint que qualquer pessoa invoca.
• Formulários bonitos sem validação no servidor. O campo tem regras no cliente; a ação aceita o que chegar.
• dangerouslySetInnerHTML para conteúdo rico. Perfeito para a demo, XSS em produção se o conteúdo for escrito por um utilizador.
• Imagens remotas com wildcard. remotePatterns com hostname: '**' para que "qualquer imagem funcione".
• Sem cabeçalhos nem CSP. O next.config sai limpo da geração.

Um bloco de instruções para o projeto

Cola-o nas instruções do projeto no v0 ou, se não as usares, no início do teu primeiro prompt, para que valha para todas as gerações:

Regras de segurança deste projeto:
- Toda a página de painel e toda a ação que leia ou escreva dados verifica a sessão no servidor. Se não houver sistema de autenticação, cria-o antes de qualquer painel.
- As chamadas a serviços com chave vão em Route Handlers ou Server Actions, nunca em componentes de cliente. Nenhuma chave secreta leva o prefixo NEXT_PUBLIC_.
- Cada Server Action e cada Route Handler valida a entrada com um esquema antes de tocar em dados.
- Passa aos componentes de cliente só os campos necessários, nunca o objeto completo do utilizador.
- Nada de dados de exemplo com credenciais; se forem precisos dados de teste, marca-os e avisa-me para os tirar antes do deploy.
- Não uses dangerouslySetInnerHTML com conteúdo de utilizador.
- images.remotePatterns lista domínios concretos. O next.config define cabeçalhos de segurança e não ativa productionBrowserSourceMaps.

Um prompt de revisão antes do deploy

Revê a segurança deste projeto e não mudes nada ainda. Responde com uma lista:
1. Páginas, Server Actions e Route Handlers que leiam ou escrevam dados sem verificar a sessão.
2. Componentes de cliente que chamem serviços externos com uma chave, e variáveis NEXT_PUBLIC_ que contenham chaves secretas.
3. Dados de exemplo, credenciais ou chaves de teste no código.
4. Ações sem validação de entrada e usos de dangerouslySetInnerHTML.
5. remotePatterns com wildcard, cabeçalhos de segurança ausentes e productionBrowserSourceMaps ativado.
Para cada ponto, propõe a alteração exata e espera pela minha confirmação.

Verifica o resultado de fora

curl -sI https://oteudominio.com | grep -iE "strict-transport|content-security|x-frame|x-content-type"
curl -s -o /dev/null -w "%{http_code}\n" https://oteudominio.com/dashboard
curl -s https://oteudominio.com | grep -oE '/_next/static/chunks/[^"]+\.js' | head -3

O esperado: cabeçalhos presentes e um redirecionamento (302 ou 307) para o login na segunda linha; um 200 significa que o painel é público. Abre os chunks do terceiro comando e procura sk_, Bearer e os nomes dos teus serviços. O Scanaris faz estas verificações e cerca de quarenta mais em 30 segundos: deteta que a app é Next.js publicada na Vercel, procura segredos nos chunks, verifica source maps, cabeçalhos, CSP, cookies, CORS e ficheiros expostos, revê os teus metadados e dá-te um fix prompt por cada falha para colar no v0. E pode voltar a analisar todos os dias, porque uma regeneração pode trazer de volta uma falha corrigida.

Perguntas frequentes

O código do v0 está pronto para produção?

A interface sim; a segurança não vem incluída. Antes de publicar algo com dados reais precisa de autenticação, validação no servidor e cabeçalhos, que é o que o bloco e o prompt acima repassam.

Fazer deploy a partir do v0 torna a minha app privada?

Não. O deploy é público como qualquer outro da Vercel, e as pré-visualizações também. A privacidade vem do teu sistema de sessão e do Deployment Protection.

O que faço se colei uma chave no chat?

Roda-a no serviço de origem mesmo que a apagues: o chat conserva-a e, se era público, qualquer pessoa já a viu. Acrescenta-a depois no painel de variáveis de ambiente e pede ao v0 que mova a chamada para o servidor.