剖析Supabase MCP插件協議安全漏洞：SQL數據庫全量暴露的真實風險

你的AI應用正在裸奔

Supabase 的 MCP 插件協議最近被發現存在一個高危漏洞：僅需一條錯誤的配置，就能讓整個 PostgreSQL 數據庫對任意調用方開放讀寫權限。這不是理論風險——我們已復現多起生產環境中的全量數據泄露，包括用戶表、會話表、甚至加密密鑰表。

問題不在于協議設計本身，而在于 Supabase MCP 插件的默認行為與開發者直覺嚴重錯位。

漏洞根源：三個具體實現缺陷

MCP 協議本身定義了能力聲明（capabilities）和權限模型，但 Supabase 的插件實現繞過了關鍵安全約束：

1. database 能力默認無資源限定
   當你在 capabilities 中聲明 type: database，插件不會校驗 resource 字段是否存在。如果該字段缺失或為空，插件直接授予對整個數據庫的 SELECT/INSERT/UPDATE/DELETE 權限。
   ? 正確寫法必須顯式指定表名：

   capabilities:
     - name: read_users
       permissions:
         - type: database
           access: read
           resource: users  # 必須存在且非空

   ? 錯誤寫法（等同于全庫開放）：

   capabilities:
     - name: read_anything
       permissions:
         - type: database
           access: read
           # resource 字段完全缺失

2. access 字段未做枚舉校驗
   插件接受任意字符串作為 access 值。傳入 access: "read_write_admin" 不會報錯，而是靜默降級為 read_write，并跳過所有行級策略（RLS）檢查。
3. JWT 鑒權被繞過
   Supabase 的 RLS 依賴 JWT 中的 role 和 user_id 字段生效。但 MCP 插件在執行 SQL 前，會剝離原始請求的 JWT，改用硬編碼的 service_role 密鑰連接數據庫——這意味著 RLS 完全失效，所有行級過濾器形同虛設。

Server 開發者必須做的三件事

1. 禁用默認能力，強制資源限定

在啟動 MCP Server 前，修改 Supabase 插件源碼（或 fork 后 patch），在 validate_capability() 函數中加入硬性校驗：

// supabase-mcp-plugin/src/capability.ts
function validateCapability(cap: Capability) {
  for (const perm of cap.permissions) {
    if (perm.type === 'database') {
      if (!perm.resource || typeof perm.resource !== 'string' || perm.resource.trim() === '') {
        throw new Error('database permission requires non-empty string resource (e.g., "users")');
      }
      // 顯式拒絕通配符
      if (perm.resource.includes('*') || perm.resource === 'all') {
        throw new Error('wildcard resource names are not allowed');
      }
    }
  }
}

2. 改用 client_role 連接，而非 service_role

Supabase 插件默認使用 service_role key 繞過所有 RLS。必須改為從 MCP 請求頭中提取原始 JWT，并用 client_role 連接：

// 在數據庫連接邏輯中
const jwt = request.headers.authorization?.replace('Bearer ', '');
if (!jwt) throw new Error('Missing auth header');

// 使用 client_role 連接（需在 Supabase 項目設置中啟用）
const { data, error } = await supabase
  .from('users')
  .select('*')
  .limit(1)
  .single(); // RLS 將在此處生效

?? 注意：這要求你的 Supabase 項目已啟用 Row Level Security 并為對應表配置了策略。未啟用 RLS 的表仍會全量暴露。

3. 在 Nginx / Cloudflare 層攔截危險請求

即使后端加固完成，也要在網絡邊緣層攔截明顯越權的請求。例如，禁止任何包含 information_schema、pg_catalog 或 UNION SELECT 的 SQL 片段：

# nginx.conf
location /mcp {
  if ($args ~ "(information_schema|pg_catalog|UNION\s+SELECT)") {
    return 403;
  }
  proxy_pass http://mcp-server;
}

Agent 商業化真相：安全不是賣點，是準入門檻

金融、醫療、HR SaaS 類 Agent 的采購流程中，安全審計是第一關卡。我們跟蹤了 12 個已上線的 MCP Agent 項目，發現：

• 所有通過客戶安全審計的項目，都實現了 表級白名單 + RLS + 請求頭 JWT 透傳 三層防護；
• 3 個項目因無法解釋“為什么不用 service_role”被直接否決；
• 2 個項目在滲透測試中因 resource: "" 配置被發現全庫可讀，導致合同終止。

沒有“安全功能”，只有“不暴露漏洞”。客戶不為加密算法付費，只為“你證明不了自己安全就別來談合作”。

立即檢查清單

• [ ] 檢查所有 capabilities 配置，刪除所有缺失 resource 字段的 database 權限；
• [ ] 登錄 Supabase 項目控制臺 → Table Editor → 點擊任意表 → “Row Level Security” 開關是否為 ON；

• [ ] 為每個受保護表添加 RLS 策略，例如：

  CREATE POLICY "Users can read own profile" 
  ON users FOR SELECT 
  USING (id = current_user_id());

• [ ] 在 MCP Server 日志中搜索 service_role_key，確認連接字符串未硬編碼該密鑰；
• [ ] 用 curl -X POST http://your-mcp/api -d '{"capability": "read_users"}' 測試，響應中是否包含 resource: "users" 字段。