# Lovableは本番環境で安全に使えますか？

Cyfendo · 2026年10月20日

Lovableは本番アプリを実行できます。個々のLovableアプリが安全かどうかは、そのアプリのために生成されたコードとデータベースのルールによって決まり、Lovableはそれらをアプリ所有者の責任として扱っています。ほとんどのLovableアプリでは、決め手となるのはSupabaseデータベースです。ブラウザは公開キーを使ってデータベースを直接読み書きしており、そのキーが到達できる範囲を制限しているのは行レベルセキュリティ（RLS）ポリシーだけです。

## CVE-2025-48757

2025年3月、研究者のMatt Palmer氏は、Lovableで構築されたアプリLinkableが、改変されたリクエストに対して`users`テーブル全体を返すことを発見しました。同氏はさらに、Lovableで構築された1,645のアプリの公開ページを調べ、そのうち170のアプリ（約10%）で303件の露出したエンドポイントを見つけました。影響を受けたアプリでは、ユーザーや取引のテーブルを、公開キーだけでサインインせずに読み取れました。あるアプリのデータベース関数は、呼び出した人すべてにGemini APIキーを返し、一部のアプリは注文の決済ステータスを変更するリクエストを受け付けていました。Palmer氏がテストしたのは、サインインせずに到達できる範囲だけです。

この問題は2025年5月下旬にCVE-2025-48757として公表され、CVSSスコアは9.3でした。米国のNational Vulnerability Databaseのエントリには、各顧客が自分のアプリのデータを保護する責任を負うという理由で、Lovableがこれに異議を唱えていることが記載されています。

欠陥があったのは各アプリ自身のポリシーだったため、プラットフォームのアップデートでは影響を受けたアプリを修正できませんでした。現在生成されるアプリでも、同じ抜け穴が生じる可能性があります。

## Lovableアプリで見られるその他の問題

- フロントエンドのコードに含まれたSupabaseのシークレットキー（`sb_secret_...`）またはレガシーの`service_role`キー。どちらもRLSを完全にバイパスします。
- サインイン済みのセッションではなくリクエスト本文からユーザーIDを取得するエッジ関数。これでは呼び出し元が任意のユーザーとして操作できてしまいます。
- 決済プロバイダーの署名付きWebhookによる確認ではなく、ブラウザが成功を報告したことで支払い済みになる注文。
- 公開バケットに保存された非公開ファイル。

## Lovableが確認する内容

[Lovableのセキュリティドキュメント](https://docs.lovable.dev/features/security)（2026年10月時点）によると、次のとおりです。

- クイックスキャンは公開ダイアログを開いたときに実行されます。RLSのないテーブル、すべての人を許可するポリシー、漏えいパスワード保護の無効化、npmパッケージの緊急レベルの脆弱性、サインインなしで露出しているMCPサーバーを探します。
- ディープスキャンはSecurityビューから開始するもので、アクセス制御の問題、認証のないエンドポイント、インジェクション、漏えいしたシークレット、決済と認証の問題、個人データの露出について、コードベースをレビューします。
- ワークスペース管理者がブロックを有効にしない限り、検出事項があっても公開はブロックされません。
- Wiz（静的解析と依存関係の解析）とAikido（AIによるペネトレーションテスト）を有料の連携機能として利用できます。

同じページには、これらのツールでは完全なセキュリティを保証できないと記載されており、機密データを扱うアプリには専門家による追加のレビューが推奨されています。

## スキャンの限界

スキャンはコードと設定を読み取ります。RLSが無効なテーブルは確実に検出します。一方、ポリシーは存在するものの許可範囲が広すぎる場合は、検出の確実性が下がります。`auth.role() = 'authenticated'`と書かれたポリシーはテーブルをサインイン済みのユーザーに限定しますが、誰でもサインアップできるため、結局すべてのアカウントがすべての行を読み取れます。このパターンを指摘するスキャナーもあれば、しないものもあります。2人目のユーザーとしてサインインし、1人目のユーザーの行をリクエストすれば、明確な答えが得られます。

もう1つのギャップはタイミングです。クイックスキャンは公開時に、ディープスキャンは誰かが開始したときに実行されますが、その間にLovableのエージェントがデータアクセスを何度も変更する可能性があります。

## 10分でできる確認

1. SupabaseのSQLエディタで、RLSのないテーブルを一覧表示します。

   ```sql
   select tablename from pg_tables
   where schemaname = 'public' and rowsecurity = false;
   ```

2. サインアウトした状態で、公開可能キーだけを使ってテーブルをリクエストします。

   ```bash
   curl "https://YOUR-PROJECT.supabase.co/rest/v1/users?select=*" \
     -H "apikey: YOUR_PUBLISHABLE_KEY"
   ```

   空のリストまたは権限エラーが返れば、そのテーブルは保護されています。行が返れば、露出しています。
3. 2つ目のテストアカウントでサインインし、1つ目のアカウントの行を読み取り、変更してみます。
4. サインインせずに`/rest/v1/rpc/`配下の各関数を呼び出し、何が返るかを確認します。
5. Lovableのディープスキャンを実行し、検出事項に順に対処します。

それぞれの修正方法は、[Lovableアプリのリリース前チェックリスト](/blog/how-to-secure-a-lovable-app)で紹介しています。

## CyfendoがLovableアプリを確認する方法

CyfendoはMCPコネクタとしてLovableに接続します。タスクがサインイン、データアクセス、Supabaseのポリシー、決済、アップロード、シークレットを変更すると、Lovableのエージェントが変更されたファイルをCyfendoに送信します。Cyfendoはプロジェクトのマイグレーションファイルから代替のSupabaseを起動し、2人のテストユーザーを作成して、上記のステップ2と3を実行します。つまり、公開キーだけで行をリクエストし、一方のユーザーとしてサインインした状態でもう一方のユーザーの行をリクエストします。再現できた問題は、修正手順とともにチャットに返されます。Cyfendoが解析できないポリシーはアクセスを拒否するものとして扱われるため、複雑なポリシーに隠れた漏えいを見逃す可能性がありますが、再現していない漏えいを報告することはありません。

セットアップにかかる時間は約2分です。[Lovableセットアップガイド](/docs/integration/lovable)をご覧ください。

Source: https://cyfendo.com/ja/blog/is-lovable-safe-for-production