FixVibe

// docs / security guides / pre-ship checklist

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

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

PRE = pre-deploy (audit your source). DEPLOY = at deploy time. POST = post-deploy verification.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  1. Verify your production domain in FixVibe. Dashboard → Domains → DNS TXT or HTTP file verification. Active scans require Hobby or above, scheduled scans require Pro or Unlimited, and live threat monitoring requires Unlimited.
  2. Schedule passive re-scans on Pro or Unlimited. Choose an available cadence for your verified domain. Scheduled runs share your scan allowance; enable completion notifications and signed webhooks as needed. A scheduled scan observes the app at run time, not continuously.
  3. Wire outbound webhooks. Account → Webhooks → HTTPS エンドポイントを追加し、scan.completed + finding.created + scan.active_api.first_used をサブスクライブします。 Slack / Discord / PagerDuty にルーティングします。
  4. Enable live threat monitoring on Unlimited. Periodic certificate, DNS, bundle, and threat-intelligence checks can surface changes between scheduled scans. Coverage and alert timing depend on the signal and successful polling.

Replit Agent

If you build with Replit Agent, also check:

  1. Don't paste keys into the Agent prompt. Add them in Secrets and give the Agent the variable name instead, so the value never appears in generated code or chat history.
  2. Test CORS on the production domain. The preview pane and your deployed URL are different origins. Check your CORS allowlist against the domain users actually load.
  3. Replit Agent sometimes hardcodes test values. エージェントは API_URL = 'http://localhost:5000</code> を使用してコードを生成する場合があります。 <code>os.environ[API_URL']に置き換えて出荷してください。

Firebase Studio

If you build with Firebase Studio, also check:

  1. Test-mode rules are temporary by intent, not by default. Test mode lets anyone read and overwrite data. If the generated rule carries a date cutoff, client access stops on that date; if not, the database stays open. Replace test rules before launch either way.
  2. Security rules protect data, not Hosting. Firestore and Storage rules don't govern what Firebase Hosting serves: everything in the public directory is public. Keep exports, backups and admin pages out of it.

Claude Code

If you build with Claude Code, also check:

  1. PRE — Keep personal Claude Code settings out of git. Commit .claude/settings.json for shared project settings, but keep .claude/settings.local.json out of the repo: Claude Code excludes it from git when it creates the file, so check it if you created it by hand. Session history lives in ~/.claude, outside the project (Claude Code docs).
  2. Bash operations are unverified. Claude Code は bash コマンドを直接実行します。 git commit -m "fix" は便利ですが、作業ディレクトリに .env ファイルがあり、グロブにそれが含まれている場合はコミットされます。 Claude Code をコミットする前に、必ず git diff --cached を確認してください。

次のステップ

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

// scan your app

読むのは終わりにして、自分のアプリの穴を見つけよう。

Drop in a URL — FixVibe runs every passive check from this guide plus the rest of its 230+ passive checks, usually in under a minute. Free, no install, no card.

  • Free 層 — 月あたり 3 回のスキャン、カードなし。
  • あらゆる URL に対するパッシブ スキャン - ドメイン検証は必要ありません。
  • Cursor、Claude Code、Lovable、Bolt、v0、Replit 用に調整されています。
  • Coding-agent prompts for code/config findings, plus operator steps for DNS/provider fixes.
無料スキャンを実行 →

サインアップ不要

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