// docs / security guides / pre-ship checklist

Vibe コーディングセキュリティチェックリスト: リリース前の 44 項目

Cursor、Claude Code、Lovable、Bolt、v0、Replit、および Windsurf を使用して構築されたアプリ用の、フェーズ別に整理された実践的なチェックリスト。各項目は 5 分以内に実行可能です。運用環境にプッシュする前に、次に各メジャーリリースの前にもう一度実行してください。項目は、シークレット、データベース、認証、ヘッダー、サードパーティ、展開、監視の 7 つのカテゴリにグループ化され、適用される展開フェーズでタグ付けされます。

PRE = 事前デプロイ (ソースを監査)。 DEPLOY = デプロイ時。 POST = デプロイ後の検証。項目は FixVibe を参照し、該当する場合は category.check-id フォームの ID を確認します。

シークレットと API キー (8 項目)

ハードコードされたキーは、バイブコード化されたアプリで最も一般的に見られるものです。侵入を防ぐための 8 つのアイテム:

PRE — Audit NEXT_PUBLIC_ env vars. 接頭辞 NEXT_PUBLIC_ が付いているものはすべてクライアントバンドルに同梱されます。キーが Supabase service_role キー ("role":"service_role" で JWT にデコードされる) の場合は、それを削除し、サーバー専用クライアント (src/lib/supabase/service.ts と import 'server-only') 経由でルーティングします。
PRE — Grep for hardcoded provider keys. sk_live_、pk_live_、STRIPE_SECRET、sk-ant-、sk-、AIza、AKIA、および JWT- の文字列 (eyJ) のソースを検索します。すべてのヒットを .env.local に移動し、process.env.* サーバー側のみを介して参照します。
PRE — Verify .gitignore. .env*.local、.npmrc、.yarnrc、およびプロバイダー固有の資格情報ファイルが無視されることを確認します。プロバイダーパターンを通じてパイプされた git ls-files を実行して、すでにコミットされているものを見つけます。
PRE — Scan the built bundle. npm run build を実行し、.next/static と同じパターンの dist/ 出力を grep します。キーがバンドルに到達した場合、開発者は環境を完全に分離できませんでした。
DEPLOY — Set secrets per environment. Vercel: 設定 → 環境変数、それぞれの範囲を Pro 誘導 / プレビュー / 開発に設定します。 sk_live_* をプレビュー環境と共有しないでください。インラインワークフローシークレットではなく、Vercel の暗号化された環境変数ストレージを使用します。
DEPLOY — Disable build-log secret echo. 一部の CI 構成 echo 環境変数はビルド時に使用されます。 vercel.json、GitHub アクションワークフロー、または Cloudflare ページ設定を監査して、値を公開ビルドログにプッシュする echo $SECRET がないか確認します。
POST — Run a passive scan. FixVibe の Free 層はこれをカバーします。デプロイされた URL を貼り付け、20 秒ほど待って、secrets.* の結果を探します。 secrets.browser-storage チェックは、SDK の誤用によって localStorage または sessionStorage に到達したキーを検出します。
POST — Rotate any key that ever shipped. キーが公開バンドルに偶数分間存在していた場合は、侵害されたものとして扱います。ダッシュボード経由で Supabase サービスロールキーをローテーションし、Stripe 制限付きキーを再生成し、コンソール経由で Anthropic / OpenAI / Google キーを取り消します。

データベースアクセス制御: RLS および Firestore ルール (6 項目)

BaaS のデフォルトは意図的に寛容になっているため、最初のチュートリアルは機能します。 Production には明示的なポリシーが必要です。

PRE — Force RLS on every public.* table. Supabase: 各テーブルには ALTER TABLE ... ENABLE ROW LEVEL SECURITY と FORCE ROW LEVEL SECURITY が必要です。 Force は重要です。これがないと、Postgres はテーブル所有者の RLS をバイパスします。
PRE — Write a policy per (table, role, action). 最小値: auth.uid() に結合する SELECT ポリシー。より良い方法: INSERT / UPDATE / DELETE ポリシーを分けて、UPDATE が所有権を変更する user_id の変更を密かに持ち込むことができないようにします。
PRE — Replace default Firebase rules. デフォルトのテストモードルールは allow read, write: if true; です。コレクションごとの認証バインドルールに置き換えます: match /users/{userId} を allow read, write: if request.auth.uid == userId; に置き換えます。
PRE — CI. での lint 移行マージ前に supabase db lint または同等のものを実行します。いずれかの CREATE TABLE public.* に一致する RLS ポリシーがない場合、CI はビルドに失敗します。
DEPLOY — Confirm RLS survived deploy. デプロイ後に Supabase Studio で再チェックします。テーブル → 各行 → RLS の切り替えは ON です。 Production データベースの移行は、ポリシーファイルよりも先を行く場合があります。ポリシーが有効であることを確認します。
POST — Run an active scan against a verified domain. baas.supabase-rls アクティブチェックは、anon キーを使用して小さなシード行に書き込み、書き込みが成功したかどうかを報告します — i.e。 RLS は実際には強制ではありません。

認証とセッション (7 項目)

AI- コード化されたアプリの認証バグは、トークン検証でのオフバイワン、HttpOnly フラグの欠落、getUser() があるべきところの getSession() など、微妙な傾向にあります。

PRE — Replace getSession() with getUser(). getSession() は Cookie を読み取り、それを信頼します。 getUser() は Supabase バックエンドで検証します。サーバールートでは常に getUser() を使用します。
PRE — Confirm token expiry. マジックリンク、パスワードリセット、および電子メール検証トークンには、サーバーによる強制有効期限が必要です。デフォルトの Supabase マジックリンクは 1 時間後に期限切れになります。特別な理由がない限り、これをより大きな数値にオーバーライドしないでください。
PRE — Verify JWT aud and exp. トークンを手動でデコードする場合は、両方のクレームを確認してください。より良い方法は、SDK の getUser() を使用することです。
PRE — Audit cookie flags. カスタムセッション Cookie は Secure; HttpOnly; SameSite=Lax (OAuth 以外のフローの場合は Strict) である必要があります。 localStorage にはセッション資料がありません。
PRE — Validate the next redirect param. サインイン後の next クエリパラメーターは、// ではなく / で始まる必要があります (attacker.example へのオープンリダイレクト)。それ以外のものはサーバー側で拒否します。
POST — Test logout. サインイン、サインアウトし、Cookie を検査します (DevTools → Application → Cookie)。セッション Cookie は同じ応答でクリアする必要があります。継続する場合、ログアウトハンドラーは実際にはサーバー側の状態を破壊していません。
POST — Active probe. active.auth-flow と active.account-enumeration チェックは、壊れた認証境界を表面化します。「ユーザーが存在する」と「パスワードが間違っています」に対する異なる応答、ログイン時のレート制限の欠落、署名されていないリセットトークンなどです。

HTTP セキュリティヘッダーとコンテンツセキュリティポリシー (6 項目)

ヘッダーはパイプライン全体の中で最も低コストの強化であり、codegen によって最も一貫してスキップされるものです。

PRE — Ship a real CSP. 最小値: script-src 'nonce-{NONCE}' 'strict-dynamic'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'。 script-src に 'unsafe-inline' がありません。 Next.js は、ミドルウェアが x-nonce リクエストヘッダーを設定するときに nonce を自動適用します。
PRE — Add the legacy three. X-Content-Type-Options: nosniff、X-Frame-Options: DENY (または CSP frame-ancestors のみに依存する)、Strict-Transport-Security: max-age=31536000; includeSubDomains。
PRE — Tighten Referrer-Policy. ほとんどのアプリではデフォルトの strict-origin-when-cross-origin で問題ありません。 unsafe-url を送信しない、またはヘッダーをまったく送信しないでください。
PRE — Replace Access-Control-Allow-Origin: *. Grep で調べてください。明示的なオリジン許可リストに置き換えます。 * と credentials: include が並んでいる場合、ブラウザはリクエストを拒否します。しかし、これはバックエンドの設定が間違っている場合の防御策にはなりません。
DEPLOY — Verify headers post-deploy. DevTools → Network → ルートドキュメントをクリック → [Headers] タブを開きます。 CSP、HSTS、X-Frame-Options、X-Content-Type-Options が存在する必要があります。 CSP には script-src に 'unsafe-inline' を含めることはできません。
POST — Run headers.security-headers. パッシブヘッダーチェックは、デプロイプラットフォーム修正ガイダンス (Vercel vercel.json、Cloudflare ページ _headers、Netlify _headers、Next.js ミドルウェア) とともに欠落している各ヘッダーを報告します。

サードパーティの統合と APIs (5 項目)

含めるすべてのスクリプトは CSP の例外であり、潜在的なサプライチェーンサーフェスです。第三者を信頼境界の一部として扱います。

PRE — Reverse-proxy analytics where possible. PostHog、Plausible、Umami はすべて、独自のドメイン (e.g. /api/posthog) を介したプロキシをサポートしています。これにより、connect-src が同じオリジンに維持され、広告ブロッカーにも耐えられます。
PRE — CSP-allowlist the rest. Google Analytics、Stripe.js、Sentry、Intercom、GTM などの場合、対応する CSP ディレクティブに各ベンダーのオリジンを追加します (ローダーの場合は script-src、テレメトリの場合は connect-src、iframe の場合は frame-src、ピクセルの場合は img-src)。
PRE — Use Stripe Checkout, not raw card forms. Stripe チェックアウトはトップレベルのリダイレクトです。スクリプトには CSP エントリは必要ありません。ホストされた PCI サーフェスは完全に Stripe のドメインに存在します。明確な理由がある場合にのみ、独自のロールを作成してください。
PRE — Lock package-lock.json in CI. 運用ビルドでは npm ci (npm install ではない) を実行します。各リリース前に npm audit または Snyk を使用して依存関係を監査します。
POST — Watch discovery.tech-fingerprint. 受動的技術スタック検出により、クローラが認識できるライブラリのバージョンが明らかになります。 EOL React、jQuery、または Bootstrap を出荷する場合、FixVibe はそれにフラグを立て、既知の CVE にリンクします。

導入の衛生状態とインフラストラクチャ (8 項目)

何をデプロイするかと同じくらい、デプロイ方法も重要です。 AI-コード化されたアプリは、明示的なデプロイの強化から特に恩恵を受けます。

PRE — Disable x-powered-by. next.config.js: poweredByHeader: false。無料バージョンの公開シグナルを削除します。
PRE — Confirm middleware lives at src/middleware.ts. src/ ディレクトリレイアウトでは、Next.js はルートレベルの middleware.ts を無視します。ミドルウェアが間違って配置されると、CSP / 認証ヘッダー / レート制限の設定がサイレントに失敗します。
PRE — Sanity-check Vercel deployment protection. Production は公開する必要があります。プレビューはパスワードで保護するか、組織メンバーに限定する必要があります。 discovery.platform-vercel が表面をレポートします。
PRE — Block dotfile and config probes at the edge. /.env、/.git/*、/.aws/*、/.next/trace パターンの書き換えまたは拒否ルールを追加します。 Vercel は、デフォルトでこれらの多くに対して 403 を返します。クロスチェック。
DEPLOY — Separate environments. Proダクション、プレビュー、開発。それぞれが独自の秘密セットを取得します。ライブキーはプレビューに到達せず、Stripe テストモードは Production に到達しません。
DEPLOY — Enable Vercel Web Application Firewall. Pro および Enterprise プランには、管理されたルールを備えた WAF が含まれます。 Cloudflare ページにはボットファイトモードがあります。どちらも、自動スキャナの悪用とパスワードスプレーの負荷を軽減します。
POST — Verify TLS configuration. SSL 実稼働ドメインに対するラボまたは testssl.sh。 TLS 1.2 以上、TLS 1.3 を優先、弱い暗号なし、HSTS プリロード対象。
POST — Confirm health-check endpoints are minimal. /api/health は本文なしで 200 OK を返す必要があります。認証なしで環境をエコーしたり、ハッシュを構築したり、タイムスタンプをデプロイしたりしないでください。

継続的なモニタリングと再スキャン（4項目）

セキュリティは、出荷前に一度だけ行う監査ではありません。ドリフトはデプロイごとに発生します。

Verify your production domain in FixVibe. Dashboard → Domains → DNS TXT または HTTP ファイル検証。これにより、スケジュールされた再スキャン、アクティブな調査、ライブ脅威監視が可能になります。
Schedule passive re-scans. Pro プランは 3 時間のリズムをサポートします。 Unlimited は 6 時間のケイデンスをサポートします。新しい発見が明らかになるスケジュールされたスキャンごとに、電子メール (有線接続している場合は Webhook) がトリガーされます。
Wire outbound webhooks. Account → Webhooks → HTTPS エンドポイントを追加し、scan.completed + finding.created + scan.active_api.first_used をサブスクライブします。 Slack / Discord / PagerDuty にルーティングします。
Enable live threat monitoring on Unlimited. 証明書の透明性ログの差分、DNS の変更、JS バンドルの秘密漏洩、脅威インテリジェンスのリスト — 次回のスケジュールされたスキャンではなく、検出された瞬間に起動されます。

次のステップ

これらの項目がなぜ重要なのかについての背景を知りたいですか? AI-generated code security scanningと読みます。各強化ステップの具体的なコードスニペットが必要ですか? How to secure an app built with AI coding toolsを参照してください。