Lovable Security Vulnerabilities 2026: 露出したキー、欠落したRLS、監査が検出するもの
Lovable セキュリティ脆弱性 2026: 公開キー、RLS の欠落、および監査が検出すること
過去 3 ヶ月間、Lovable で MVP を構築した後にクライアントが持ち込んだアプリケーションを監査してきました。パターンは非常に一貫しており、ほぼ退屈なほどです: クライアント バンドルで公開された Supabase サービスキー、RLS ポリシーゼロ、DevTools を持つ誰でも取得できる JavaScript に直接置かれたハードコードされた OpenAI と Stripe シークレット。毎回です。
これは Lovable への批判ではありません。このプラットフォームはプロトタイピングにとって本当に素晴らしいです。しかし「機能するデモ」と「本番対応アプリケーション」の間には峡谷ほどの大きな違いがあり、Lovable はその峡谷にあるもののほとんどについて教えてくれません。コミュニティ研究者が AI で構築された 50 のアプリを監査し、ほぼすべてのアプリで同じ 5 つのセキュリティ上の問題を発見しました。別の開発者が 200 以上のバイブコーディングされたサイトをスキャンし、100 点中平均 52 点のセキュリティスコアを発見しました。最も悪い事例は特に Lovable + Supabase アプリケーションに集中しています。
継続的に発見しているすべての脆弱性、Lovable 独自のツールがそれらを逃す理由、およびそれぞれを修正する方法を正確に説明しましょう。
目次
- 問題を引き起こす構造
- 脆弱性 1: クライアントコードで公開された Supabase キー
- 脆弱性 2: 欠落または破損している RLS ポリシー
- 脆弱性 3: ハードコードされたサードパーティ API シークレット
- 脆弱性 4: セキュリティヘッダーの欠落
- 脆弱性 5: 入力検証またはサニタイズなし
- Lovable の組み込みセキュリティスキャンが実際にチェックすること
- 本番監査がプラットフォームが検出しないことをキャッチするもの
- Moltbook インシデント: 実世界のケーススタディ
- Lovable アプリを本番に進める前に修正する方法
- 自動スキャン用ツール
- FAQ
問題を引き起こす構造
Lovable アプリが不均衡に影響を受ける理由を理解するには、構造を理解する必要があります。Lovable は Supabase をバックエンドとして排他的に使用します。Firebase オプション、カスタムバックエンド、脱出ハッチはありません。Lovable で何かを構築すると、クライアントライブラリを使用して Supabase REST API と直接通信する React フロントエンドが生成されます。
Supabase は、anon キーが公開で安全に公開されるように設計されています。これは本質的にプロジェクト識別子です。セキュリティモデルはまったく PostgreSQL レベルのRow Level Security (RLS) ポリシーに依存しています。このように考えてください:
| コンポーネント | 公開されることを想定? | 何があなたを保護するか |
|---|---|---|
| Supabase URL | はい | 何も必要ない - ただの URL です |
anon キー |
はい | すべてのテーブルの RLS ポリシー |
service_role キー |
絶対いいえ | サーバー側のみに保つ必要があります |
| データベース接続文字列 | いいえ | クライアントに公開しないでください |
問題は、Lovable の AI がこれらすべてを同じように扱うコードを生成することです。anon キーをフロントエンドに配置します (問題ありません)。ただし、RLS を有効にしないテーブルを作成します (壊滅的)。時々 service_role キーもクライアントコードに入ります (終わり)。Reddit の開発者がいったように: 「AI はあなたが頼むことをします。頼まなかったことについては考えません。」
脆弱性 1: クライアントコードで公開された Supabase キー
すべての Lovable アプリは Supabase クライアントを次のような方法で初期化します:
// src/integrations/supabase/client.ts
import { createClient } from '@supabase/supabase-js'
const supabaseUrl = 'https://xyzcompany.supabase.co'
const supabaseAnonKey = 'eyJhbGciOiJIUzI1NiIs...'
export const supabase = createClient(supabaseUrl, supabaseAnonKey)
anon キーがここにあることは問題ありません - これは仕様によるものです。問題は 2 つの形式で来ます:
`service_role` キーのリーク
Lovable で生成されたコードを見たことがあります。ここで service_role キーはクライアント側のコードで終了します。通常、「RLS がそれをブロックしていても、これが機能するようにしてください」というような AI にプロンプトを与えた場合です。AI のソリューション? 管理者キーを使用します。service_role キーはすべての RLS ポリシーを完全にバイパスします。フロントエンドバンドルにある場合、誰でもそれを抽出し、データベース全体に完全な読み取り/書き込みアクセスを持つことができます。
`.env` ファイルが Git にコミットされたもの
GitHub にデプロイされた Lovable プロジェクトは、.env ファイルがリポジトリにコミットされていることがよくあります。リポジトリが今は非公開でも、以前は公開されていた場合 - たとえ 1 分間でも - これらのキーは危険にさらされています。ボットはこの正確なパターンのために継続的に GitHub をスクレイピングします。
確認する方法:
# service_role キーをコードベースで検索する
grep -r "service_role" --include="*.ts" --include="*.tsx" --include="*.js" --include="*.env" .
# 誤ってコミットされたシークレットのための git 履歴を確認する
git log --all -p -- '*.env'
修正方法: クライアントコードからすぐに service_role キーを削除します。Supabase ダッシュボードでキーをローテーションします (設定 → API)。キーはサーバー側のコードのみで使用します - Supabase Edge Functions、Next.js API ルート、または別のバックエンド。
脆弱性 2: 欠落または破損している RLS ポリシー
これが大きなものです。CVE-2025-48757 は 170 以上の Lovable で構築されたアプリケーション全体の 303 の脆弱なエンドポイントを公開しました。Escape.tech によると、公開された Supabase データベースの 83% が RLS の設定ミスに関連しています。
Lovable がテーブルを作成するときにデフォルトで何が起こるかです:
-- Lovable がしばしば生成するもの
CREATE TABLE user_profiles (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
user_id UUID REFERENCES auth.users(id),
full_name TEXT,
email TEXT,
created_at TIMESTAMPTZ DEFAULT now()
);
-- 何が欠けているのか見ることができますか? RLS は有効になっていません。
-- このテーブルは、anon キーを持つ誰でも完全に読み取り可能で書き込み可能です。
RLS がない場合、Supabase データベースは本質的にパブリック API です。プロジェクト URL と anon キーを知っている誰でも - どちらもフロントエンドコードにあります - これを行うことができます:
// 攻撃者のブラウザコンソール
const { data } = await supabase.from('user_profiles').select('*')
// すべてのユーザーのデータを返します
await supabase.from('user_profiles').delete().neq('id', '')
// すべてを削除します
RLS 障害の 3 つのフレーバー
| 障害モード | 何が起こるか | 深刻度 |
|---|---|---|
| RLS がまったく有効になっていない | 完全なパブリック読み取り/書き込みアクセス | 重大 |
| RLS は有効でしたが、ポリシーが定義されていない | 誰もアクセスできません (アプリが壊れます) | 高 (RLS を無効にするよう開発者を強制します) |
過度に寛容なポリシー (例: USING (true)) |
セキュアに見えますが、実際にはそうではありません | 高 |
3 番目のものは特に不吉です。「権限を修正する」ことを求めるとき、Lovable が生成したポリシーを見ました:
CREATE POLICY "Allow all access" ON user_profiles
FOR ALL
USING (true)
WITH CHECK (true);
これは RLS シアターです。有効で、ポリシーがあり、何もしません。
適切なポリシーは何に見えるか:
-- RLS を有効にする
ALTER TABLE user_profiles ENABLE ROW LEVEL SECURITY;
-- ユーザーは自分のプロフィールのみを読むことができます
CREATE POLICY "Users read own profile" ON user_profiles
FOR SELECT
USING (auth.uid() = user_id);
-- ユーザーは自分のプロフィールのみを更新できます
CREATE POLICY "Users update own profile" ON user_profiles
FOR UPDATE
USING (auth.uid() = user_id)
WITH CHECK (auth.uid() = user_id);
-- 認証されたユーザーのみが挿入でき、自分たちのためにのみ
CREATE POLICY "Users insert own profile" ON user_profiles
FOR INSERT
WITH CHECK (auth.uid() = user_id);
脆弱性 3: ハードコードされたサードパーティ API シークレット
これは毎回気が進みません。React コンポーネントに直接ハードコードされた OpenAI API キー (sk-...)、Stripe シークレットキー (sk_live_...)、SendGrid キー、およびその他の認証情報を定期的に見つけます。
// 実際に Lovable で生成されたファイルで見つかった
const openai = new OpenAI({
apiKey: 'sk-proj-abc123...', // これはあなたのブラウザバンドルにあります
})
DevTools を開き、Sources タブに移動して sk- または sk_live を検索する人は誰でもあなたのキーを取得します。攻撃者はこれを自動化します。JavaScript バンドルを具体的に検索しているボットがあります。
財務的な影響は実際です。クライアントは、公開された OpenAI キーが週末中に $4,200 の料金をもたらした後、私たちのところに来ました。Stripe シークレットキーはさらに悪いです - それは払い戻しを処理し、顧客データを表示し、サブスクリプションを変更する完全なアクセスを与えます。
修正: すべてのサードパーティ API 呼び出しをサーバー側の関数に移動します。Supabase Edge Functions はこれに適しています:
// supabase/functions/openai-proxy/index.ts
import { serve } from 'https://deno.land/std@0.168.0/http/server.ts'
serve(async (req) => {
const { prompt } = await req.json()
const response = await fetch('https://api.openai.com/v1/chat/completions', {
method: 'POST',
headers: {
'Authorization': `Bearer ${Deno.env.get('OPENAI_API_KEY')}`,
'Content-Type': 'application/json',
},
body: JSON.stringify({
model: 'gpt-4o',
messages: [{ role: 'user', content: prompt }],
}),
})
return new Response(JSON.stringify(await response.json()))
})
脆弱性 4: セキュリティヘッダーの欠落
200 以上のサイトスキャンでは、ほとんどの Lovable デプロイアプリがセキュリティヘッダーゼロで出荷されていることがわかりました。Content-Security-Policy はありません。Strict-Transport-Security はありません。X-Frame-Options はありません。X-Content-Type-Options はありません。
これはデータベースの露出と比較して軽微に見えるかもしれませんが、ヘッダーが欠落すると次が可能になります:
- クリックジャッキング - あなたのアプリは悪意のあるサイトの iframe に埋め込まれることができます
- XSS 増幅 - CSP がなければ、注入されたスクリプトには制限がありません
- MIME タイプ嗅ぎ攻撃 - ブラウザは実行可能コードとしてファイルを解釈する可能性があります
- ダウングレード攻撃 - HSTS がない場合、トラフィックが傍受される可能性があります
| ヘッダー | 目的 | Lovable デフォルト |
|---|---|---|
| Content-Security-Policy | XSS を防止し、リソース読み込みを制御します | 欠落 |
| Strict-Transport-Security | HTTPS を強制します | 欠落 |
| X-Frame-Options | クリックジャッキングを防止します | 欠落 |
| X-Content-Type-Options | MIME スニッフィングを防止します | 欠落 |
| Referrer-Policy | リファラー情報を制御します | 欠落 |
| Permissions-Policy | ブラウザ機能を制御します | 欠落 |
脆弱性 5: 入力検証またはサニタイズなし
Lovable で生成されたフォームは通常、検証なしでユーザー入力を直接 Supabase に送信します。長さチェック、型検証、HTML またはSQL 関連コンテンツのサニタイズがありません。
Supabase の PostgREST レイヤーは従来の SQL インジェクションを防止しますが、入力検証の欠落は依然として次を可能にします:
- テキストフィールドの非サニタイズ HTML を通じた保存 XSS
- 極めて大きなペイロードを通じたサービス拒否
- ビジネスロジックの悪用 (例: 負の数量、$0.00 の価格)
- 予期しないタイプによるデータ破損
Lovable の組み込みセキュリティスキャンが実際にチェックすること
Lovable にはダッシュボードからアクセス可能な組み込みの「セキュリティスキャン」機能があります。功績があるところに - それは存在します。しかし、実際に掩蔽するものと掩蔽しないものは次の通りです:
| チェック | 組み込みスキャン | 本番監査 |
|---|---|---|
| 基本的な構文エラー | ✅ | ✅ |
| 既知の依存関係 CVE | 部分的 | ✅ |
| ソースコードでハードコードされたシークレット | ❌ | ✅ |
| すべてのテーブルで RLS が有効 | ❌ | ✅ |
| RLS ポリシーの正確性 | ❌ | ✅ |
| Service role キーの露出 | ❌ | ✅ |
| セキュリティヘッダー | ❌ | ✅ |
| 入力検証カバレッジ | ❌ | ✅ |
| 認証の構成レビュー | ❌ | ✅ |
| ストレージバケットのポリシー | ❌ | ✅ |
| レート制限 | ❌ | ✅ |
| クッキーのセキュリティフラグ | ❌ | ✅ |
組み込みスキャンは最良でも表面的です。実際に悪用される脆弱性をキャッチしません。
本番監査がプラットフォームが検出しないことをキャッチするもの
Lovable で構築したクライアントの本番セキュリティ監査を行うときは、実際に検出して修正する内容を以下に示します。これは実際の業務からの実際のリストです:
データベースレイヤー
- RLS が無効になっているテーブル (平均: テーブルの 60-70%)
trueを条件として使用する RLS ポリシー- DELETE 操作の欠落ポリシー (開発者は削除について忘れます)
- 結合/結合テーブルのポリシーなし
- アップロード制限のないパブリックに設定されているストレージバケット
- RLS ポリシー条件で使用されている列のインデックスが欠落 (パフォーマンス + セキュリティ)
認証レイヤー
- 弱い JWT シークレット (Supabase のデフォルトは問題ありませんが、時々人々がそれらを変更します)
- 電子メール確認要件の欠落
- 認証エンドポイントのレート制限なし
- トークンの有効期限切れが適切でないパスワードリセットフロー
- OAuth リダイレクト URL の設定ミス
クライアントコードレイヤー
- フロントエンドバンドルの
service_roleキー - コンポーネントでハードコードされたサードパーティ API キー
- git 履歴にコミットされた
.envファイル - ユーザーデータを console で公開するデバッグロギング
- データベーススキーマ情報を漏らしるエラーメッセージ
インフラストラクチャレイヤー
- セキュリティヘッダーまったくなし
Secure、HttpOnly、またはSameSiteフラグのないクッキー- 公開されたサーバーバージョン情報
- CORS 設定なし (あらゆるオリジンからリクエストを受け入れます)
- 数か月間更新されていない既知 CVE の依存関係
監査する典型的な Lovable アプリは、本番準備ができるまでに 15-25 個の修正が必要です。そのほとんどは 1 時間以下で対応できますが、まず存在することを知る必要があります。
Moltbook インシデント: 実世界のケーススタディ
2026 年 1 月、Wiz のセキュリティ研究者は、Moltbook - AI ソーシャルネットワーク - が設定ミスされたクライアントを通じて Supabase データベース全体を公開していることを発見しました。anon キーはフロントエンド JavaScript にありました (通常)。しかし RLS は重要なテーブルで構成されませんでした (壊滅的)。
結果? 150 万の API キーがアクセス可能でした。単なるユーザーデータではなく - OpenAI、Anthropic、および他のアカウントをコネクトした接続されたユーザーが所有する実際の API キー。すべてのテーブルへの完全な読み取りおよび書き込みアクセス。研究者はブラウザコンソールで Supabase クライアントを使用するだけでデータベース全体を参照できました。
開示タイムラインはきつかった - Moltbook のメンテナーは連絡を受けた数時間以内に重要なテーブルを修正しました。しかし損害ウィンドウは不明でした。データベースが誰かがチェックする前に何時間公開されていましたか? 誰も知りません。
これは Lovable + Supabase パターンが大規模で再生されています。プラットフォームは機能するコードを生成します。単にセキュアなコードを生成しません。
Lovable アプリを本番に進める前に修正する方法
ここは私たちが使用するチェックリストです。SQL と Supabase のダッシュボードで快適であれば、自分でこのほとんどを行うことができます:
ステップ 1: RLS のためにすべてのテーブルを監査する
-- Supabase SQL エディターでこれを実行して RLS なしでテーブルを見つける
SELECT schemaname, tablename, rowsecurity
FROM pg_tables
WHERE schemaname = 'public';
rowsecurity が false のテーブルには即座の対応が必要です。
ステップ 2: シークレットのためにコードベースを検索する
# 一般的なシークレットパターンを検索する
grep -rn 'sk-' --include='*.ts' --include='*.tsx' --include='*.js' .
grep -rn 'sk_live' --include='*.ts' --include='*.tsx' --include='*.js' .
grep -rn 'service_role' --include='*.ts' --include='*.tsx' --include='*.js' .
grep -rn 'SUPABASE_SERVICE' --include='*.ts' --include='*.tsx' --include='*.env' .
ステップ 3: 適切な RLS ポリシーを書く
すべてのテーブルについて、SELECT、INSERT、UPDATE、DELETE の明示的なポリシーを書きます。常に auth.uid() チェックを使用します:
-- ユーザー所有テーブルのテンプレート
ALTER TABLE your_table ENABLE ROW LEVEL SECURITY;
CREATE POLICY "select_own" ON your_table FOR SELECT
USING (auth.uid() = user_id);
CREATE POLICY "insert_own" ON your_table FOR INSERT
WITH CHECK (auth.uid() = user_id);
CREATE POLICY "update_own" ON your_table FOR UPDATE
USING (auth.uid() = user_id)
WITH CHECK (auth.uid() = user_id);
CREATE POLICY "delete_own" ON your_table FOR DELETE
USING (auth.uid() = user_id);
ステップ 4: API 呼び出しをサーバー側に移動する
シークレットキーが必要なサードパーティ API 呼び出しは、Supabase Edge Function または別のバックエンドで実行する必要があります。これは交渉の余地のないものです。
ステップ 5: セキュリティヘッダーを追加する
Netlify、Vercel、または Cloudflare にデプロイしている場合は、その構成でヘッダーを追加します。Netlify の場合、_headers ファイルを作成します。Next.js アプリの場合は、それらを next.config.js で追加します。
ステップ 6: フレームワークマイグレーションを検討する
MVP を超えるすべてのもので、Lovable で生成された React コードを適切な Next.js または Astro プロジェクトに移行することをしばしば推奨しています。これはサーバー側の API ルート、適切な環境変数処理、認証チェック用のミドルウェア、および実際のビルドパイプラインを提供します。最初はより多くの作業ですが、セキュリティ姿勢は昼夜ほど異なります。
自動スキャン用ツール
AI で生成されたアプリの監査に特化した複数のツールが出現しました:
| ツール | チェック対象 | コスト |
|---|---|---|
Ship Safe (npx ship-safe audit .) |
RLS、service_role 露出、ストレージバケット、依存関係 CVE | 無料、オープンソース |
| Vibe App Scanner (vibeappscanner.com) | AI で構築されたアプリの完全セキュリティスキャン | 無料スタータースキャン |
| Snyk | 依存関係の脆弱性、コードスキャン | 無料階層利用可能 |
| Supabase ダッシュボード → 認証 → ポリシー | ビジュアル RLS ポリシーエディター | Supabase に含まれる |
Ship Safe は始めるのに選ぶべきものです。ローカルで実行され、何もマシンを離れず、AI ツールが作成する Supabase の設定ミスに特化して構築されています:
npx ship-safe audit .
RLS が無効に、service_role キーがクライアントコードに、開かれたストレージバケット、弱い認証設定、ハードコードされたシークレット、および依存関係 CVE にフラグを立てます。
FAQ
Supabase anon キーはフロントエンドコードで公開しても安全ですか?
はい - ただしすべてのテーブルに適切な RLS ポリシーがある場合のみ。anon キーはパブリックになるように設計されています。プロジェクト識別子のようなものです。セキュリティは、そのキーが実際にアクセスできるものを制御する RLS ポリシーから来ます。RLS がない場合、anon キーはすべてのユーザーに完全なデータベースアクセスを与えます。
Lovable はテーブルを作成するときにデフォルトで RLS を有効にしますか?
いいえ。2026 年初頭の時点で、Lovable は RLS を有効にせずに Supabase テーブルを作成します。これはプラットフォームの単一最大のセキュリティギャップです。Lovable が生成した後、各テーブルの RLS を手動で有効にし、ポリシーを書く必要があります。CVE-2025-48757 はこのデフォルト動作の直接的な結果でした。
Lovable アプリが公開されたシークレットを持っているかどうかをどのように確認しますか?
デプロイされたアプリをブラウザで開き、DevTools (F12) を開き、Sources タブに移動し、すべてのファイルで sk-、sk_live、service_role、および使用するサービスの API キープレフィックスを検索します。また、コードベースで自動検出用にローカルで npx ship-safe audit . を実行します。
Lovable の組み込みセキュリティスキャンは RLS の問題をキャッチできますか?
組み込みセキュリティスキャンは RLS の設定ミス、欠落ポリシー、または公開されたサービスキーをチェックしません。基本的なコードレベルの問題をカバーしますが、最高のリスクを表す損害とインフラストラクチャ脆弱性を逃します。実際のセキュリティ評価には外部ツールが必要です。
CVE-2025-48757 はどうなりましたか?
CVE-2025-48757 は、Lovable で構築された 170 以上のアプリ全体の 303 の脆弱なエンドポイントを特定した脆弱性開示でした。根本的な原因は Lovable が RLS を有効にせずに Supabase テーブルを作成し、公開で利用可能な anon キーを持つ誰でもデータベース全体にアクセスできるようにしていました。これは問題の体系的な性質を強調しました。
本番アプリのために Lovable から移動すべきですか?
必ずしも。Lovable は急速なプロトタイピングと MVP 構築に優れています。しかし、本番使用前に、生成されたコードはかなりのセキュリティ強化が必要です。多くのチームは Lovable を使用して初期バージョンを構築してから、サーバー側レンダリング、適切なシークレット管理、およびセキュリティミドルウェアを備えた適切なフレームワークに移行します。それは合理的なアプローチです。
Lovable アプリを本番のために保護するのにどのくらい時間がかかりますか?
10-20 テーブルを持つ典型的なアプリについて、すべての RLS ポリシーを監査し、シークレットをサーバー側に移動し、セキュリティヘッダーを追加し、入力を検証し、すべてをテストするために 2-5 日の集中作業を予想してください。ストレージバケット、リアルタイムサブスクリプション、複数のユーザーロールを持つより複雑なアプリはより長くかかることができます。それは不可能な作業ではありませんが、それは 1 時間の作業でもありません。
Bolt や Cursor のような他の AI アプリビルダーは Lovable よりも安全ですか?
200 以上のサイトスキャンでは、セキュリティ脆弱性が Lovable + Supabase アプリケーションに特化して集中していることがわかりました。Bolt、Replit、および Cursor/Cline ベースのアプリは同じパターンの RLS 設定ミスを示しませんでした。それはそれらが完全にセキュアであるという意味ではありません - すべての AI 生成コードはレビューが必要です - しかし Lovable 特有の Supabase 統合は他のツールが持たない一意のクラスのデータベース露出脆弱性を作成します。