Lovable で作ったアプリを公開する前に：リリース前のセキュリティチェックリスト

Lovable は、アイデアを動くプロダクトにするまでの時間を、これまでのどんなツールよりも短くしました。セキュリティ面の機能もあり、公開のたびにデータベースのよくある問題をスキャンし、AIによるより詳しいコードレビューも提供しています。両方とも使ってください。多くの問題を見つけてくれますが、Lovable 自身も、アプリの安全性までは保証できないとしています。

足りないのは、スキャナーには判断できない部分です。あなたのアプリのどのデータが非公開なのか、誰に何を許可すべきか、想定外の使い方をされたら何が起きるか。このチェックリストはその部分を扱います。リリース前に一度、大きな変更のあとにもう一度確認してください。

データベース #

1. すべてのテーブルで Row Level Security が有効になっている。 AIツールが使う SQL で作られたテーブルは、初期状態では有効になりません。一覧の出し方は 10分でできる Supabase チェックで紹介しています。

2. 非公開のテーブルに、すべてを許可するルールがない。 profiles、orders、messages に using (true) のルールがあれば、RLS の有無にかかわらず誰でも読めます。

3. ユーザーが自分の権限を引き上げられない。 profiles テーブルに role、is_admin、plan などの列があり、ユーザーが自分の行を更新できる場合、その列もブラウザから1回のリクエストで書き換えられます。権限や課金状態は、サーバー側のコードだけが書き込める別のテーブルに保存するか、更新ルールで変更できる列を制限してください。

select table_name, column_name
from information_schema.columns
where table_schema = 'public'
  and column_name ~* '(role|admin|plan|credits|verified|status)';

結果を、RLS チェックで確認した update のルールと照らし合わせます。

キー #

4. フロントエンドにシークレットキーがない。 公開中のアプリを sb_secret_ と service_role で検索します。見つかったら、シークレットキーが漏れたときの最初の1時間の対応に従ってください。

5. 外部サービスの秘密情報もフロントエンドにない。 AI、決済、メールのキーはサーバー側の関数に置きます。sk-、sk_live、re_ を検索し、VITE_ で始まる環境変数をすべて確認してください。サーバー側の関数に移す方法も参考にしてください。

ストレージ #

6. 個人に関わるファイルは非公開バケットにある。 アバター画像は公開でも構いませんが、身分証、請求書、契約書は違います。各ユーザーが自分のフォルダにしかアクセスできないようにします。Storage のチェック。

7. バケットにサイズとファイル形式の制限がある。 制限がなければ、アップロードを許可された人は何でも保存でき、費用はあなたの負担になります。

ログイン #

8. メールアドレスの確認が有効になっている。 無効にする理由がない限り、有効にしておきます。無効だと、他人のメールアドレスで登録できてしまいます。

9. リダイレクト先 URL を自社のドメインに限定している。 Supabase の Authentication → URL Configuration で、Site URL を本番のドメインにし、実際に使うアドレスだけを登録します。不要になった localhost やプレビュー用のアドレスは削除してください。

10. 招待制のアプリなら、新規登録を閉じている。 新規登録が開いている社内ツールは、公開アプリと同じです。

11. 管理画面はすべてサーバー側で権限を確認している。 ボタンを隠すだけではアクセス制御になりません。管理者向けのページや操作なら、その裏にあるデータを、権限を確認するルールまたはサーバー側の関数で守り、API を直接呼んでも何も返らないようにします。

決済と関数 #

12. 金額はサーバー側で決めている。 ブラウザが伝えるのは何を買うかだけで、価格はサーバーが調べます。ブラウザから金額を受け取る関数は、いずれ 0.01 を送りつけられます。

13. 決済の Webhook を署名で検証している。 どんなリクエストも信用する Webhook のエンドポイントがあれば、誰でも注文を支払い済みにできます。

14. Edge Functions が呼び出し元を確認している。 データを読む、お金を使う、メールを送る関数はすべて、ユーザーを確認し、入力を検証する必要があります。誰でも呼べる関数がひとつあるだけで、データベースのルールはすべて無意味になります。

復旧 #

15. 昨日のデータをどう復元するかわかっている。 Supabase の Database → Backups を開き、ご利用のプランに何が含まれているかを確認してください。下位のプランでは、ほとんど何もないこともあります。AIの誤った編集やマイグレーションの失敗ひとつで、テーブルが消えることがあります。データが大切なら、テスト用のプロジェクトに実際に一度復元したことのあるバックアップを用意しておきましょう。

リリース後 #

セキュリティは一度で終わりではありません。新しいプロンプトのたびに、ルールのないテーブル、間違った場所に置かれたキー、ブラウザを信用する関数が加わる可能性があります。次の2つの習慣が役立ちます。

• リリース時だけでなく、大きな変更のたびに Lovable のスキャンと Supabase の Security Advisor を実行する。
• 作成したばかりの RLS ルールや関数について、AIに平易な言葉で説明させる。説明が意図と合わなければ、詳しく確認するタイミングです。

リリース前に第三者の目で確認したい場合は、無料の Security Check をご利用ください。これらの項目を外部から読み取り専用で確認し、深刻な問題を48時間以内に書面でお伝えします。修正が必要な場合は、作業前にお見積もりした固定料金で Security Fix が対応します。