Lovable 安全漏洞 2026：洩露的密鑰、缺失的 RLS 和審計能捕捉到的內容
我在過去三個月審計了用戶用 Lovable 建立 MVP 後帶來的應用程式。這個模式非常一致，幾乎有點無聊：暴露的 Supabase 服務金鑰在客戶端程式碼中、零個 RLS 政策、硬編碼的 OpenAI 和 Stripe 密鑰就在 JavaScript 裡，任何人用 DevTools 就能取得。每一次都是這樣。
這不是對 Lovable 的批評。這個平台對於原型製作來說確實令人印象深刻。但「能運行的演示」和「可上線的應用程式」之間有一個很大的差距，而 Lovable 沒有告訴你這個差距中大部分的內容是什麼。一個社群研究人員審計了 50 個 AI 建立的應用程式，發現其中幾乎所有應用程式都存在相同的五個安全漏洞。另一個開發者掃描了 200+ 個 vibe-coded 網站，發現平均安全分數為 100 分中的 52 分——最差的情況集中在 Lovable + Supabase 應用程式。
讓我們逐一檢視我們不斷發現的每個漏洞、為什麼 Lovable 自身的工具會遺漏它們，以及如何精確地修復每一個。
目錄
- 造成問題的架構
- 漏洞 1：客戶端程式碼中暴露的 Supabase 金鑰
- 漏洞 2：缺少或損壞的 RLS 政策
- 漏洞 3：硬編碼的第三方 API 密鑰
- 漏洞 4：缺少安全標頭
- 漏洞 5：沒有輸入驗證或清理
- Lovable 的內建安全掃描實際檢查的內容
- 生產審計捕捉的是平台沒有的內容
- Moltbook 事件：真實世界案例研究
- 在上線前修復 Lovable 應用程式的方法
- 自動掃描工具
- 常見問題
造成問題的架構
要了解為什麼 Lovable 應用程式受到的影響不成比例，你需要了解架構。Lovable 專門使用 Supabase 作為其後端。沒有 Firebase 選項、沒有自訂後端、沒有逃生口。當你在 Lovable 中建立東西時，它會生成一個直接使用客戶端庫與 Supabase REST API 通話的 React 前端。
Supabase 的設計使得 anon 金鑰可以安全地公開暴露——它本質上是一個專案識別碼。安全模型完全依賴於 PostgreSQL 層級的列級安全 (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 金鑰在這裡沒問題——這是設計的。問題有兩種形式：
`service_role` 金鑰洩露
我們見過 Lovable 生成的程式碼中 service_role 金鑰最終出現在客戶端程式碼中，通常是因為某人向 AI 提示「即使 RLS 阻止它也要讓它運行」。AI 的解決方案？使用管理員金鑰。service_role 金鑰完全繞過所有 RLS 政策。如果它在你的前端程式碼中，任何人都可以提取它並完全讀寫存取你的整個資料庫。
`.env` 檔案被提交到 Git
經常將 Lovable 專案部署到 GitHub 時，.env 檔案被提交到儲存庫。即使儲存庫現在是私有的——即使只是一分鐘——那些金鑰已經被洩露。機器人不斷掃描 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，83% 的暴露 Supabase 資料庫涉及 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 失敗的三種情況
| 失敗模式 | 發生什麼 | 嚴重性 |
|---|---|---|
| 完全沒有啟用 RLS | 完全公開讀寫存取 | 危急 |
| 啟用了 RLS 但沒有定義政策 | 沒有人可以存取任何東西（應用程式損壞） | 高（強制開發者停用 RLS） |
過於寬容的政策（例如 USING (true)） |
看起來安全，實際上不是 | 高 |
第三個特別陰險。當被提示「修復權限」時，我們見過 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 密鑰
每次都會讓我退縮。我們經常發現 OpenAI API 金鑰（sk-...）、Stripe 密鑰（sk_live_...）、SendGrid 金鑰和其他認證資料直接硬編碼在 React 元件中。
// 實際上在一個 Lovable 生成的檔案中找到的
const openai = new OpenAI({
apiKey: 'sk-proj-abc123...', // 這在你的瀏覽器程式碼中
})
任何打開 DevTools、進入「來源」標籤並搜尋 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 部署的應用程式運行時沒有安全標頭。沒有內容安全政策。沒有嚴格傳輸安全。沒有 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 金鑰暴露 | ❌ | ✅ |
| 安全標頭 | ❌ | ✅ |
| 輸入驗證覆蓋 | ❌ | ✅ |
| 驗證配置審查 | ❌ | ✅ |
| 儲存貯體政策 | ❌ | ✅ |
| 速率限制 | ❌ | ✅ |
| Cookie 安全旗標 | ❌ | ✅ |
內建掃描最多只是表面層級。它不會捕捉實際被利用的漏洞。
生產審計捕捉的是平台沒有的內容
當我們對為在 Lovable 上建立的客戶進行生產安全審計時，以下是我們通常發現和修復的內容。這是真實的清單，來自實際的參與：
資料庫層
- 禁用 RLS 的表（平均：60-70% 的表）
- 使用
true作為條件的 RLS 政策 - 缺少 DELETE 操作的政策（開發者忘記了刪除）
- 在交集/連接表上沒有政策
- 設置為公開的儲存貯體，沒有上傳限制
- RLS 政策條件中使用的列上缺少索引（效能 + 安全性）
驗證層
- 弱 JWT 密鑰（Supabase 預設值沒問題，但有時人們會改變它們）
- 缺少電子郵件確認要求
- 驗證端點上沒有速率限制
- 沒有適當的代幣過期的密碼重設流程
- OAuth 重定向 URL 配置錯誤
客戶端程式碼層
- 前端程式碼中的
service_role金鑰 - 在元件中硬編碼的第三方 API 金鑰
.env檔案被提交到 git 歷史- 在控制台中暴露使用者資料的除錯記錄
- 洩露資料庫架構資訊的錯誤訊息
基礎設施層
- 完全沒有安全標頭
- 沒有
Secure、HttpOnly或SameSite旗標的 Cookie - 暴露的伺服器版本資訊
- 沒有 CORS 配置（接受來自任何來源的請求）
- 包含已知 CVE 的相依性未在數月內更新
一個典型的我們審計的 Lovable 應用程式在上線前需要 15-25 項修復。其中大多數耗時不到一小時，但你需要先知道它們的存在。
Moltbook 事件：真實世界案例研究
2026 年 1 月，Wiz 的安全研究人員發現 Moltbook——一個 AI 社交網路——其整個 Supabase 資料庫因錯誤配置的客戶端而暴露。anon 金鑰在前端 JavaScript 中（正常），但 RLS 沒有在關鍵表上配置（災難性的）。
結果？150 萬個 API 金鑰可以存取。不只是使用者資料——實際上屬於已連接其 OpenAI、Anthropic 和其他帳戶的使用者的 API 金鑰。完整的讀寫存取每個表。一個研究人員只需使用瀏覽器控制台中的 Supabase 客戶端就可以瀏覽整個資料庫。
披露時間線很緊湊——Moltbook 的維護者在被聯繫後幾小時內修復了關鍵表。但損害視窗是未知的。資料庫在有人檢查之前暴露多長時間？沒有人知道。
這是 Lovable + Supabase 模式大規模發揮的情況。該平台生成工作程式碼。它只是不生成安全程式碼。
在上線前修復 Lovable 應用程式的方法
以下是我們使用的清單。如果你熟悉 SQL 和 Supabase 儀表板，你可以自己完成大部分工作：
第一步：審計每個表的 RLS
-- 在 Supabase SQL 編輯器中執行以查找沒有 RLS 的表
SELECT schemaname, tablename, rowsecurity
FROM pg_tables
WHERE schemaname = 'public';
rowsecurity 為 false 的任何表都需要立即注意。
第二步：搜尋你的程式碼中是否有密鑰
# 搜尋常見的密鑰模式
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' .
第三步：編寫適當的 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);
第四步：將 API 呼叫移至伺服器端
任何需要密鑰的第三方 API 呼叫都需要在 Supabase Edge Function 或單獨的後端中執行。這是不可談判的。
第五步：新增安全標頭
如果你要部署到 Netlify、Vercel 或 Cloudflare，請透過其配置新增標頭。對於 Netlify，建立一個 _headers 檔案。對於 Next.js 應用程式，在 next.config.js 中新增它們。
第六步：考慮框架遷移
對於超越 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。
常見問題
Supabase anon 金鑰在前端程式碼中暴露安全嗎？
是的——但只有在你在每個表上都有適當的 RLS 政策時。anon 金鑰設計為公開。它就像一個專案識別碼。安全來自 RLS 政策，控制該金鑰實際可以存取的內容。沒有 RLS，anon 金鑰給任何人完整的資料庫存取權。
Lovable 在建立表時預設啟用 RLS 嗎？ 否。至 2026 年初，Lovable 建立 Supabase 表時沒有預設啟用 RLS。這是平台中最大的單一安全差距。在 Lovable 生成表後，你需要手動啟用 RLS 並為每個表編寫政策。CVE-2025-48757 是這個預設行為的直接結果。
我如何檢查我的 Lovable 應用程式是否有暴露的密鑰？
在瀏覽器中打開你部署的應用程式，打開 DevTools (F12)，進入「來源」標籤，並搜尋所有檔案以查找 sk-、sk_live、service_role 以及你使用的服務的任何 API 金鑰首碼。同時在你的程式碼上本地執行 npx ship-safe audit . 進行自動偵測。
Lovable 的內建安全掃描可以捕捉 RLS 問題嗎？ 內建安全掃描不檢查 RLS 錯誤配置、缺少政策或暴露的服務金鑰。它涵蓋基本的程式碼層級問題，但遺漏代表最高風險的資料庫和基礎設施漏洞。你需要外部工具進行真實的安全評估。
CVE-2025-48757 發生了什麼？ CVE-2025-48757 是一個漏洞披露，識別了用 Lovable 建立的 170+ 個應用程式中的 303 個易受攻擊的 API 端點。根本原因是 Lovable 建立 Supabase 表而不啟用 RLS，讓整個資料庫對任何有公開可用 anon 金鑰的人都可以存取。它強調了問題的系統性質。
我應該為生產應用程式遠離 Lovable 嗎？ 不一定。Lovable 非常適合快速原型製作和建立 MVP。但生成的程式碼在生產使用前需要顯著的安全強化。許多團隊使用 Lovable 建立初始版本，然後遷移到具有伺服器端渲染、適當密鑰管理和安全中介軟體的適當框架。這是一種合理的方法。
保護 Lovable 應用程式以便上線需要多長時間？ 對於具有 10-20 個表的典型應用程式，預計 2-5 天的集中工作來審計所有 RLS 政策、將密鑰移至伺服器端、新增安全標頭、驗證輸入和測試一切。具有儲存貯體、即時訂閱和多個使用者角色的更複雜應用程式可能需要更長時間。這不是無法克服的，但這也不是一小時的工作。
Bolt 或 Cursor 等其他 AI 應用程式建構器比 Lovable 更安全嗎？ 200+ 個網站的掃描發現安全漏洞集中在 Lovable + Supabase 應用程式中。Bolt、Replit 和基於 Cursor/Cline 的應用程式沒有顯示相同的 RLS 錯誤配置模式。這並不意味著它們完全安全——所有 AI 生成的程式碼都需要審查——但 Lovable 特定的 Supabase 整合建立了其他工具沒有的獨特資料庫暴露漏洞類別。