AI で作ったアプリのための修正ガイド
バイブコーディングによるローンチを台無しにするセキュリティの穴と、それぞれを正確に塞ぐ方法。わかりやすい言葉でのステップを、実際のリスクに応じて優先順位付けしています。
- critical→
Lovable アプリに行レベルセキュリティ（RLS）を追加する方法
Lovable は Supabase データベースをプロビジョニングしますが、テーブルを公開 anon キーで読み取り可能なまま残すことがよくあります。行レベルセキュリティのポリシーを有効化して記述するまで、誰でもユーザーのデータを読み取れてしまいます。
- critical→
Supabase で行レベルセキュリティ（RLS）を有効化する方法
RLS のない Supabase テーブルは、anon キーを持つ人なら誰でも完全に読み取れます。その anon キーはフロントエンドと一緒に配布されます。RLS を正しく有効化することは、Supabase アプリを安全にするうえで最も重要な唯一のステップです。
- critical→
露出した Supabase キーを修正する方法
2 つのケースがあります。anon キーは公開されることが前提です。露出したのがそれだけなら、RLS が修正手段になります。しかし、service-role キーがクライアントや公開リポジトリに到達した場合、データベース全体が露出しているため、直ちにローテーションしなければなりません。
- critical→
露出した API キーをローテーションする方法
フロントエンドや公開リポジトリに出てしまった API キーは、漏洩したものとして扱うべきです。ある創業者は Stripe のシークレットキーをフロントエンドにリリースしてしまい、ローテーションする前に 175 人の顧客に請求が発生しました。素早く、しかし正しい順序でローテーションしてください。
- medium→
アプリにセキュリティヘッダーを追加する方法
AI で生成されたアプリは、ほぼ必ずセキュリティヘッダーなしでリリースされ、クリックジャッキング、プロトコルダウングレード、コンテンツインジェクション攻撃にさらされます。これらの追加は手早く、効果が大きい対策です。
- medium→
CORS エラーを安全な方法で修正する方法
CORS エラーの最も手早い「修正」、つまりワイルドカードですべてのオリジンを許可することは、セキュリティの穴でもあります。どんな Web サイトでも、被害者のブラウザからあなたの API を呼び出せてしまうのです。正しい修正は、信頼するオリジンだけを許可することです。
- critical→
環境変数とシークレットを安全にする方法
AI で作ったアプリは、シークレットをクライアント側の環境変数に入れたり、.env ファイルをコミットしたり、バンドルの中で露出させたりして、日常的にシークレットを漏らしています。ブラウザにあるものはすべて公開状態です。シークレットはサーバー側だけに置かなければなりません。
- high→
Supabase RLS のベストプラクティス
RLS の有効化は、仕事の半分にすぎません。緩すぎる、または誤ったポリシーは、RLS が「オン」でもデータを露出させたままにします。これらが、Supabase の行レベルセキュリティに本当にデータを守らせるためのプラクティスです。
- critical→
Firebase のセキュリティルールを安全にする方法
Firebase のデータ漏洩の第 1 の原因は、ルールがテストモード（「allow read, write: if true」）のまま残されていることで、これはデータベース全体を公開状態にします。安全なルールは、すべての読み書きを認証済み・認可済みのユーザーに制限します。
修正するだけでなく、検証もしてほしいですか？
修正は第一歩にすぎません。ClearedToShip のレビューなら、修正が本当に有効かを確認し、ローンチのための署名入り・保険付きのクリアランスを発行します。早期アクセスに参加：