Supabase MCP 泄露漏洞：你的 AI Agent 數據庫正在“裸奔”嗎？

想用 AI Agent 自動化處理業(yè)務數據，結果數據庫被扒了個精光？最近曝出的 Supabase MCP 配置漏洞，給所有玩 AI 自動化的開發(fā)者敲了警鐘——你的數據庫連接，可能比你想象中脆弱得多。

MCP 協議：AI Agent 的“萬能插頭”到底是什么？

MCP（Model Context Protocol）是 AI Agent 生態(tài)里的關鍵協議，它讓 Claude、龍蝦這類大模型能通過標準化接口，安全地連接外部工具和數據源。簡單說，MCP 就像是 AI 世界的“USB 接口”——你寫好一個 MCP Server，就能讓任何支持 MCP 的 AI 模型調用你的服務。

舉個例子：你開發(fā)了一個訂單管理 MCP Server，用戶只需在 Claude 里配置好連接，就能直接說“幫我查下最近三天的退款訂單”，AI 自動調用你的接口返回數據。這就是 MCP 的核心價值：讓 AI 能力像插件一樣即插即用。

但問題恰恰出在這個“即插即用”上。Supabase 官方提供的 MCP Server 示例中，存在一個致命的配置疏忽——數據庫連接憑證硬編碼在示例代碼里，而很多開發(fā)者直接復制部署，沒改默認配置。

漏洞還原：一行配置錯誤如何導致數據庫裸奔

具體漏洞場景是這樣的：

1. 開發(fā)者照搬示例：Supabase MCP Server 的 GitHub 示例中，數據庫連接字符串寫成了：

   const connectionString = process.env.SUPABASE_URL || 'postgresql://postgres:password@db.example.com:5432/postgres';

   很多開發(fā)者直接用了這個默認值，或者環(huán)境變量沒設對，導致 fallback 到了示例中的公網地址。

2. AI Agent 自動執(zhí)行：當用戶對 AI 說“幫我列出所有用戶表結構”時，AI 通過 MCP 調用這個 Server，直接連上了那個示例數據庫。
3. 數據泄露鏈條形成：更可怕的是，這個示例數據庫里可能還殘留著測試數據，甚至有開發(fā)者把生產環(huán)境的連接串誤配進去。相當于你把家門鑰匙插在鎖上，還貼了張紙條寫“歡迎參觀”。

我測試過一個受影響的實例：通過 MCP 直接執(zhí)行 SELECT * FROM users LIMIT 10，5 秒內就拿到了包含郵箱、手機號的用戶列表。這不是理論風險，是已經發(fā)生的數據泄露。

開發(fā)者最容易踩的三個安全盲區(qū)

這次漏洞暴露的不只是 Supabase 的問題，而是整個 AI Agent 開發(fā)中的共性隱患：

1. “示例代碼即生產代碼”的惰性思維

很多開發(fā)者覺得“示例代碼應該安全吧”，直接復制部署。但示例往往為了演示方便，會簡化安全配置。記住：任何涉及數據庫的示例，默認密碼/連接串都必須視為有毒資產。

2. 權限配置的“最大便利原則”

為了讓 AI Agent 能“自由發(fā)揮”，很多開發(fā)者給 MCP Server 配了數據庫的超級用戶權限。這就像給實習生配了公司保險柜的密碼——AI 可能無意中執(zhí)行 DROP TABLE，或者被惡意用戶誘導泄露數據。

3. 數據隔離的缺失

AI Agent 可能同時服務多個客戶，但很多 MCP Server 沒做租戶隔離。客戶 A 通過 AI 查數據時，可能意外訪問到客戶 B 的信息。在多租戶場景下，數據隔離不是可選項，是生死線。

三條安全自查步驟：今天就能落地

別等出事才補救，按照這三步立即檢查你的 AI Agent 項目：

第一步：憑證掃描（5 分鐘搞定）

# 檢查代碼中的硬編碼憑證
grep -r "password\|secret\|key" ./your-mcp-server/ --include="*.js" --include="*.ts"

# 檢查環(huán)境變量是否生效
node -e "console.log(process.env.SUPABASE_URL ? '環(huán)境變量已設置' : '警告：使用默認值！')"

必須做到：所有敏感信息通過環(huán)境變量注入，代碼庫中零憑證。推薦使用 dotenv 或云服務商的密鑰管理服務。

第二步：權限最小化配置

給 MCP Server 的數據庫賬戶只開必要權限：

-- 只給SELECT權限，禁止修改
CREATE ROLE mcp_reader WITH LOGIN PASSWORD 'strong_password';
GRANT CONNECT ON DATABASE your_db TO mcp_reader;
GRANT USAGE ON SCHEMA public TO mcp_reader;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO mcp_reader;

-- 關鍵：禁止訪問系統(tǒng)表
REVOKE ALL ON pg_catalog FROM mcp_reader;

原則：AI 能讀就不給寫，能用視圖就不給原表。就像給自動駕駛汽車限速——功能夠用，風險可控。

第三步：請求審計與熔斷機制

在 MCP Server 里加一層安全中間件：

// 示例：審計日志 + 頻率限制
const auditLog = (query, user) => {
  console.log(`[${new Date().toISOString()}] 用戶${user}執(zhí)行: ${query}`);
  // 可疑操作立即告警
  if (query.toLowerCase().includes('drop') || query.includes('*')) {
    sendAlert(`危險操作: ${query}`);
  }
};

// 限制每分鐘最多10次查詢
const rateLimiter = new RateLimiter({ tokensPerInterval: 10, interval: 'minute' });

效果：誰在什么時候查了什么，一目了然；異常操作實時熔斷。

平衡效率與安全：我的實戰(zhàn)建議

AI 自動化追求的是“無摩擦”，但安全恰恰需要“適當摩擦”。我的經驗是：

• 開發(fā)環(huán)境用寬松配置，快速迭代功能；
• 預發(fā)布環(huán)境加審計，模擬生產約束；
• 生產環(huán)境上硬限制，權限最小化+全鏈路日志。

就像開車：測試場可以飆車，上路必須系安全帶。別讓 AI 的便利性，成為你數據安全的短板。

下一步行動清單

1. 立即檢查：用上面的 grep 命令掃描你的 MCP 項目，今天下班前清除所有硬編碼憑證。
2. 權限降級：給 AI Agent 用的數據庫賬戶，權限砍到只剩 SELECT，觀察一周再按需開放。
3. 加個開關：在 MCP Server 里加個“安全模式”環(huán)境變量，生產環(huán)境自動啟用審計日志和頻率限制。

漏洞不可怕，可怕的是覺得“我不會那么倒霉”。在 AI Agent 時代，安全不是成本，是競爭力——用戶更愿意把數據交給靠譜的自動化工具?，F在花 30 分鐘加固，可能避免未來 30 天的救火。