vibe-security

AI によるコード生成でよく発生するセキュリティ脆弱性がないか、コードを監査します。こうした問題は、「バイブコーディング」で作られたアプリでよく見られます。AI の支援を受けて急いで構築され、セキュリティの基本が見落とされたプロジェクトです。

AI アシスタントはこうしたパターンを繰り返し誤るため、実際の情報漏えい、API キーの窃取、課金アカウントの不正利用につながっています。このスキルは、問題がリリースされる前に発見するためのものです。

基本原則

クライアントを決して信頼してはいけません。価格、ユーザー ID、ロール、サブスクリプションの状態、機能フラグ、レート制限カウンターは、すべてサーバー側で検証または適用する必要があります。ブラウザー、モバイルバンドル、リクエスト本文にしか存在しない情報は、攻撃者が制御できます。

監査プロセス

コードベースを体系的に確認します。各ステップでは、コードベースで該当するテクノロジーやパターンが使われている場合に限り、関連するリファレンスファイルを読み込みます。該当しないステップはスキップしてください。

1. シークレットと環境変数 — ハードコードされた API キー、トークン、認証情報がないかスキャンします。クライアント側の環境変数プレフィックス（NEXT_PUBLIC_、VITE_、EXPO_PUBLIC_）を介してシークレットが公開されていないか確認します。.env が .gitignore に含まれていることを確認します。references/secrets-and-env.md を参照してください。

2. データベースのアクセス制御 — Supabase の RLS ポリシー、Firebase Security Rules、または Convex の認証ガードを確認します。これは、バイブコーディングされたアプリにおける重大な脆弱性の発生源として第 1 位です。references/database-security.md を参照してください。

3. 認証と認可 — JWT の処理、ミドルウェア認証、Server Action の保護、セッション管理を検証します。references/authentication.md を参照してください。

4. レート制限と不正利用の防止 — 認証エンドポイント、AI 呼び出し、高コストな操作にレート制限があることを確認します。レート制限カウンターを改ざんできないことを検証します。references/rate-limiting.md を参照してください。

5. 決済セキュリティ — クライアント側での価格改ざん、Webhook 署名の検証、サブスクリプション状態の検証を確認します。references/payments.md を参照してください。

6. モバイルセキュリティ — トークンが安全に保存されていること、バックエンドプロキシによって API キーが保護されていること、ディープリンクが検証されていることを確認します。references/mobile.md を参照してください。

7. AI / LLM の統合 — AI API キーの公開、利用上限の欠如、プロンプトインジェクションの侵入経路、安全でない出力のレンダリングがないか確認します。references/ai-integration.md を参照してください。

8. デプロイ設定 — 本番環境の設定、セキュリティヘッダー、ソースマップの公開、環境の分離を確認します。references/deployment.md を参照してください。

9. データアクセスと入力検証 — SQL インジェクション、ORM の誤用、入力検証の欠如がないか確認します。references/data-access.md を参照してください。

部分的なレビューを行う場合や、特定の領域のコードを生成する場合は、該当するリファレンスファイルのみを読み込みます。

基本的な指示

• 実際に存在するセキュリティ上の問題だけを報告します。スタイルやセキュリティ以外の問題を細かく指摘しないでください。
• 複数の問題がある場合は、悪用のしやすさと現実世界への影響を基準に優先順位を付けます。
• コードベースで特定のテクノロジー（例：Supabase）が使われていない場合、そのセクションは完全にスキップします。
• 新しいコードを生成する場合は、脆弱性を最初から持ち込まないよう、関連するリファレンスファイルを事前に確認します。
• 重大な問題（シークレットの公開、RLS の無効化、認証の回避）を見つけた場合は、回答の冒頭ですぐに指摘し、長いリストの中に埋もれさせないでください。

出力形式

指摘事項を重大度順に整理します：重大 → 高 → 中 → 低。

各問題について：

1. ファイル名と該当する行を示します。
2. 脆弱性の名称を示します。
3. 攻撃者が実行できることを、抽象的なリスクではなく具体的な影響として説明します。
4. 修正前と修正後のコードを示します。

問題がない領域は省略します。最後に優先順位付きの概要を記載します。

出力例

重大

lib/supabase.ts:3 — Supabase の service_role キーがクライアントバンドルで公開されています

service_role キーは、すべての行レベルセキュリティを回避します。誰でもブラウザーバンドルからキーを抽出し、データベース内のすべての行を読み取り、変更、削除できます。

// Before
const supabase = createClient(url, process.env.NEXT_PUBLIC_SUPABASE_SERVICE_KEY!)

// After — use the anon key client-side; service_role belongs only in server-side code
const supabase = createClient(url, process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!)

高

app/api/checkout/route.ts:15 — 価格がクライアントのリクエストボディから取得されています

攻撃者はリクエストを改変して、任意の価格（0.01 ドルを含む）を設定できます。価格はサーバー側で検索する必要があります。

// Before
const session = await stripe.checkout.sessions.create({
  line_items: [{ price_data: { unit_amount: req.body.price } }]
})

// After — look up the price server-side
const product = await db.products.findUnique({ where: { id: req.body.productId } })
const session = await stripe.checkout.sessions.create({
  line_items: [{ price: product.stripePriceId }]
})

まとめ

1. サービスロールキーの露出（重大）： 誰でもデータベースのセキュリティをすべて回避できます。直ちにキーをローテーションし、サーバー側のみで使用するようにしてください。
2. クライアントによる価格の制御（高）： 攻撃者は任意の価格で購入できます。サーバー側で価格を検索してください。

コードを生成する際

これらのルールは事前対策としても適用されます。認証、決済、データベースアクセス、API キー、またはユーザーデータを扱うコードを書く前に、該当するリファレンスファイルを確認し、脆弱性を最初から持ち込まないようにしてください。検出より予防が重要です。

リファレンス

• references/secrets-and-env.md — API キー、トークン、環境変数の設定、および .gitignore のルール。
• references/database-security.md — Supabase RLS、Firebase Security Rules、および Convex の認証パターン。
• references/authentication.md — JWT の検証、ミドルウェア、Server Actions、およびセッション管理。
• references/rate-limiting.md — レート制限の戦略と不正利用の防止。
• references/payments.md — Stripe のセキュリティ、Webhook の検証、および価格の検証。
• references/mobile.md — React Native と Expo のセキュリティ：セキュアストレージ、API プロキシ、ディープリンク。
• references/ai-integration.md — LLM API キーの保護、使用量の上限、プロンプトインジェクション、および出力のサニタイズ。
• references/deployment.md — 本番環境の設定、セキュリティヘッダー、および環境の分離。
• references/data-access.md — SQL インジェクションの防止、ORM の安全性、および入力の検証。