// Segurança por ferramenta
Segurança para apps feitos no v0
Resposta rápida
O v0 gera UI e código muito bons, mas o risco não está no componente isolado, está em como você integra: um dangerouslySetInnerHTML colado sem sanitizar, uma chave de API hardcoded num client component, um handler de formulário que confia no input do usuário, e o app deployado sem CSP. Nenhum desses o v0 resolve por você; eles aparecem na costura entre o gerado e o seu backend.
Se você montou o produto colando peças do v0, a revisão certa olha a fronteira: onde entra input, onde vive segredo, e o que o server action realmente valida antes de escrever no banco.
O que costuma passar batido no v0
O padrão do v0 é UI-first com server actions e route handlers do Next. O gerado funciona, mas o v0 escreve fluxo funcional, não fluxo seguro, sem instrução explícita. Os pontos que mais quebram:
| Furo | Por que acontece | Impacto |
|---|---|---|
| dangerouslySetInnerHTML | Snippet colado renderiza HTML sem sanitizar | XSS via conteúdo do usuário |
| Chave em client component | Segredo hardcoded no que roda no browser | Credencial exposta no bundle |
| Server action sem authz | Action funcional que não checa dono do dado | IDOR / escrita indevida |
| Sem CSP no deploy | App publicado sem Content-Security-Policy | Superfície maior pra injeção |
Como a RET revisa um app feito no v0
A RET testa a costura: cada server action e route handler é checado por quem pode chamar, com qual validação e se confere o dono do recurso. Procura dangerouslySetInnerHTML sem sanitização, segredo em client component e ausência de CSP. Achado com reprodução e prioridade.
Pra rodar sozinho, o Promptbook cobre esses pontos com prompt direto. Sinal sério vai pro Risk Review.
- Auditoria de cada server action: quem chama, o que valida, checa dono?
- Busca por dangerouslySetInnerHTML e segredo em componente client.
- Conferência de CSP e headers no app deployado.
Você já pode estar exposto se
Sinais que pedem revisão num app v0:
- Você usa dangerouslySetInnerHTML com conteúdo que vem do usuário.
- Alguma chave de API está num arquivo que roda no client.
- Seus server actions gravam no banco sem checar o dono do dado.
- O app foi publicado sem Content-Security-Policy.
Perguntas frequentes
O código do v0 é inseguro?
Não por si só. O v0 gera código funcional e limpo; o risco aparece na integração, quando um snippet com dangerouslySetInnerHTML, uma chave no client ou um server action sem checagem de dono entra no seu app sem revisão. É a costura que precisa de olho.
Server action do Next é seguro por padrão?
Ele roda no servidor, o que ajuda, mas não valida authz sozinho. Uma action que escreve no banco precisa checar se o usuário logado é dono daquele recurso, senão vira IDOR. O v0 escreve a action funcional; a checagem de dono é sua.
Preciso mesmo de CSP?
CSP reduz muito o estrago de um XSS, que é justamente o risco de colar dangerouslySetInnerHTML. Publicar sem CSP não é um bug isolado, mas amplia qualquer injeção. Vale configurar antes de receber usuário real.
Quem faz a revisão na RET?
Gabriel Lima Ferreira, founder e lead pentester, com autorização e escopo fechado.