What are v0.dev security best practices?

The best practices specific to v0.dev (not generic OWASP)

Every "security best practices" list tells you to use HTTPS and rotate keys. Those are table stakes. The list below is what actually matters for v0.dev apps, based on the risks that appear in real v0.dev deployments.

1. Search for dangerouslySetInnerHTML

*Why:* AI may suggest React patterns that render unsanitized user content. *Do this:* Search for dangerouslySetInnerHTML. Sanitize all dynamic HTML with DOMPurify.

2. Add server-side validation for all form inputs

*Why:* v0 generates UI but not server-side validation logic. *Do this:* Add server-side validation for all form inputs. Never trust client-side only.

3. Review all fetch/API calls

*Why:* Generated code may include placeholder URLs or fake endpoints. *Do this:* Review all fetch/API calls. Replace placeholders before deployment.

4. Implement real auth with NextAuth

*Why:* UI-only auth flows that can be bypassed. *Do this:* Implement real auth with NextAuth.js, Clerk, or Supabase Auth.

5. Run npm audit after installation

*Why:* Suggested packages may have known vulnerabilities. *Do this:* Run npm audit after installation. Update vulnerable packages.

v0.dev-specific: audit every table for RLS before every deploy

The failure mode in v0.dev + Supabase apps is always the same: a table gets added during a feature push, RLS never gets turned on, the full table becomes queryable via the anon key. Bake a pre-deploy check: `select tablename from pg_tables where schemaname = 'public' and not rowsecurity` — the result must be empty.

Verification

Even perfect best practices don't prove themselves — the only way to confirm the list above is implemented is to scan a deployed v0.dev app. VAS probes each of xss prevention, secret detection, security headers, auth patterns by actually attempting the attack, not just reading headers or docs.