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 で生成されたアプリは、ほぼ必ずセキュリティヘッダーなしでリリースされ、クリックジャッキング、プロトコルダウングレード、コンテンツインジェクション攻撃にさらされます。これらの追加は手早く、効果が大きい対策です。
修正するだけでなく、検証もしてほしいですか？
修正は第一歩にすぎません。ClearedToShip のレビューなら、修正が本当に有効かを確認し、ローンチのための署名入り・保険付きのクリアランスを発行します。早期アクセスに参加：