// docs / security guides / v0 checklist
v0 security checklist: 22 items for Next.js
v0 generates React + Tailwind + shadcn/ui components and full Next.js apps for Vercel. This checklist targets v0-specific risks: design iterations that re-add dangerouslySetInnerHTML, exported codebases that lose middleware, Server Actions that skip auth verification, and environment variables that have to be set again once the code lives in your own repo. 22 items across secrets, database, auth, headers, deployment, and v0-specific gotchas.
PRE = pre-deploy (audit your source). DEPLOY = at deploy time. POST = post-deploy verification.
シークレットと API キー (4 項目)
v0 はエディターで環境変数を適切に処理しますが、エクスポートされたリポジトリはその構造を継承しません。
- PRE — After exporting, audit all
NEXT_PUBLIC_vars in the exported.env. 接頭辞NEXT_PUBLIC_が付いているものはすべてクライアント バンドルに同梱されています。安全であることを確認します (API エンドポイント、anon キーのみ、サービス ロールは使用しない)。 - PRE — Verify
.env.local(or.env.*.local) is in.gitignore. v0 からエクスポートする場合、エクスポートされたリポジトリには.gitignoreに.env*.localが含まれている必要があります。これを確認してください。 - PRE — Check that v0 didn't hardcode Stripe / Anthropic / OpenAI test keys. v0 のエクスポートされたコードには、コンポーネントにハードコーディングされた
sk_test_*キーやpk_test_*キーが含まれる場合があります。運用環境にデプロイする前に、環境変数に置き換えます。 - POST — Run Secrets in JavaScript Bundles on the deployed Vercel Preview. キーがバンドルに到達すると、スキャンによってそれが検出されます。
データベースアクセス制御（3項目）
v0 のデータ取得は通常、Next.js サーバー アクションを介して行われます。データベース接続自体はサーバー側ですが、RLS ポリシーは明示的である必要があります。
- PRE — If using Supabase, enable RLS on every public table. v0 doesn't generate RLS by default. Add
ENABLE ROW LEVEL SECURITYto everyCREATE TABLEmigration. - PRE — Write explicit RLS policies per table and role. 各ポリシーは
auth.uid()を通じてユーザーの所有権を検証する必要があります。 - POST — Run the Supabase Row-Level Security active check on a verified domain. このチェックにより、RLS の施行が確認されます。
認証とセッション (4 項目)
v0 は認証をスキャフォールディングしますが、サーバー側の検証を自動的に強制しません。
- PRE — Ensure Server Actions use
getUser(), notgetSession(). サーバー アクション関数内のgetSession()をawait supabase.auth.getUser()に置き換えます。 - PRE — Verify that magic-link tokens have server-enforced expiry. デフォルトの Supabase は 1 時間です。 v0 で生成されたコードがそれをオーバーライドする場合は、デフォルトに戻します。
- PRE — Check the sign-in redirect guard.
nextパラメータは/で始める必要があり、//は使用できません。通常、v0 にはこれが含まれていますが、確認してください。 - POST — Test logout clears the session. サインイン、サインアウトし、Cookie を検査します (DevTools → Application → Cookie)。セッション Cookie をクリアする必要があります。
HTTP ヘッダーと CSP (3 項目)
v0 のエクスポートされたアプリには、CSP のミドルウェアが必要です。編集者の内部 CSP は引き継がれません。
- PRE — Create
src/middleware.tswith CSP if it doesn't exist. v0 はミドルウェアなしでエクスポートする場合があります。欠落している場合は、ノンスベースの CSP を使用して生成します。 - エディタ内の PRE — Verify CSP includes
'strict-dynamic'and a per-request nonce. v0 の CSP は安全ですが、エクスポートされたバージョンは不完全である可能性があります。 - POST — Run HTTP Security Headers on a Vercel Preview. スキャンでは、欠落しているヘッダーと修正ガイダンスが報告されます。
展開時の衛生管理 (5 項目)
v0 は GitHub リポジトリにエクスポートされ、Vercel にデプロイされます。環境設定はお客様の責任で行ってください。
- DEPLOY — Verify
.env.localis in.gitignorein the exported repo.git ls-files .env*を実行して確認してください。 - DEPLOY — Set production env vars in Vercel Settings → Environment Variables. それぞれのスコープは Production のみです。
sk_live_*をプレビューと共有しないでください。 - DEPLOY — Audit Vercel build logs for secret echo. ビルド コマンドに
echo $SECRETまたは同等のものが含まれていないことを確認してください。 - DEPLOY — Confirm Vercel Preview redeploys work correctly. 各プレビュー展開では、新しい CSP ノンスを生成する必要があります。
- POST — Rotate any test key that reached production.
sk_test_*キーであっても、プロダクション公開後にローテーションする必要があります。
v0 固有の注意事項 (3 項目)
v0 のエディターからリポジトリへのエクスポートに固有のパターン:
dangerouslySetInnerHTMLcan come back during design iterations. Review each exported version and replace any occurrences with sanitized alternatives (likereact-markdownwithremark).- Exported middleware is sometimes incomplete. v0 の
src/middleware.tsエクスポートには CSP または HSTS が欠けている可能性があります。デプロイする前に、完了していることを確認してください。 - Server Actions don't automatically verify auth. v0 は、組み込みの認証チェックを行わずにサーバー アクションを生成します。状態を変更するすべてのサーバー アクションに
const { user } = await supabase.auth.getUser()を手動で追加します。
次のステップ
51 個のクロスツール項目については general vibe coding security checklist を確認してください。次に、step-by-step hardening を参照して、CSP、RLS、サーバー アクションのセキュリティに関する詳細なパターンを確認してください。