警惕Supabase MCP插件安全風險：MCP生態(tài)中的安全加固指南

Supabase MCP插件暴露全量數(shù)據(jù)庫的問題

Supabase MCP插件默認配置允許未經(jīng)鑒權的 API 請求直接觸發(fā) SELECT * FROM 查詢，且不校驗用戶身份、角色或行級權限（RLS）。只要攻擊者知道項目 URL 和公開的 service_role 密鑰（或通過其他方式獲取有效 JWT），就能導出整個 PostgreSQL 數(shù)據(jù)庫。

這不是理論風險。我們復現(xiàn)過：用 curl -X GET "https://<project>.supabase.co/rest/v1/users?select=*"，配合一個泄露的 service key，拿到 27 萬條用戶記錄，包括郵箱、密碼哈希（bcrypt）、注冊 IP 和最后登錄時間。

問題核心在于插件把 MCP 的 get_data 操作直連到 Supabase REST API，而后者在未啟用 RLS 或未配置策略時，對 service_role 完全放行。

MCP 協(xié)議本身不處理權限

MCP 規(guī)范（v0.7）定義了 get_data、run_tool 等操作的 JSON Schema 和傳輸格式，但沒規(guī)定：

• 誰能調(diào)用這些操作
• 操作能訪問哪些數(shù)據(jù)字段或表
• Server 是否必須校驗 Agent 身份

它假設權限由底層系統(tǒng)（如 Supabase、Postgres）兜底，但現(xiàn)實里很多部署跳過了這層校驗。

結果就是：Agent 發(fā)起一個 get_data 請求，Server 直接轉(zhuǎn)發(fā)給數(shù)據(jù)庫，中間沒有身份透傳、沒有作用域限制、沒有審計日志。

實操加固方案

1. 鎖死 Supabase MCP 插件配置

• 禁用 service_role 密鑰：在 Supabase 項目設置中關閉 service_role 密鑰生成，改用 anon + RLS
• 強制啟用 RLS 并寫策略：對每張表至少加一條策略，例如：

-- users 表只允許讀取自己的記錄
CREATE POLICY "users_select_own" ON public.users
  FOR SELECT USING (auth.uid() = id);

• 重寫插件的數(shù)據(jù)獲取邏輯：不要直接代理 REST API，改用 Supabase Client SDK，在 Server 端用 supabase.auth.signInWithPassword() 或 supabase.auth.setAuth() 注入用戶上下文，再調(diào)用 from().select()。

2. MCP Server 必須做三件事

• 所有入口路由強制校驗 JWT，并解析 role、user_id、permissions 字段
• 每個 get_data 請求必須映射到預定義的數(shù)據(jù)源白名單（如 ["users", "orders"]），禁止動態(tài)表名
• 對返回數(shù)據(jù)執(zhí)行字段過濾：即使數(shù)據(jù)庫查出 20 列，也只返回策略允許的 3 列（如 id, name, created_at）

示例中間件（Express）：

const supabase = createClient(
  process.env.SUPABASE_URL,
  process.env.SUPABASE_ANON_KEY
);

app.post('/mcp/get_data', async (req, res) => {
  const authHeader = req.headers.authorization;
  if (!authHeader?.startsWith('Bearer ')) return res.status(401).send();

  const token = authHeader.split(' ')[1];
  const { data: user, error } = await supabase.auth.getUser(token);
  if (error || !user) return res.status(403).send();

  const { table, columns = ['*'], filter } = req.body;

  // 白名單檢查
  if (!['users', 'products', 'orders'].includes(table)) {
    return res.status(400).json({ error: 'invalid table' });
  }

  // 字段過濾（示例：users 表只允許返回 id 和 name）
  const safeColumns = table === 'users' 
    ? ['id', 'name', 'created_at'] 
    : columns;

  let query = supabase.from(table).select(safeColumns.join(','));

  if (filter?.user_id && table === 'orders') {
    query = query.eq('user_id', filter.user_id);
  }

  const { data, error: dbError } = await query;
  if (dbError) return res.status(500).json({ error: dbError.message });

  res.json({ data });
});

3. Agent 部署守則

• Agent 啟動時只注入最小 scope 的 JWT（例如 role=agent_readonly），絕不使用 service_role
• 禁用 Agent 的任意代碼執(zhí)行能力（如 eval、Function 構造函數(shù)、shell 命令）
• 所有出向請求必須帶 X-Agent-ID 和簽名頭，Server 端驗證來源合法性
• 每次 get_data 調(diào)用記日志：Agent ID、用戶 ID、表名、字段列表、響應行數(shù)、耗時

4. 傳輸與存儲加固

• Server 與 Agent 之間強制 TLS 1.3，禁用降級協(xié)商
• 敏感字段（密碼哈希、手機號、身份證號）在數(shù)據(jù)庫層加密（pgcrypto + encrypt()），密鑰由 Vault 管理，不硬編碼
• 日志脫敏：自動替換匹配 \b\d{17}[\dXx]\b（身份證）、\b1[3-9]\d{9}\b（手機號）的字符串為 ***

商業(yè)化落地的真實約束

某客服 SaaS 公司上線 MCP Agent 后遭遇 GDPR 審計，關鍵整改項只有兩條：

• 把 get_data 接口拆成原子化 endpoint：/api/v1/users/me、/api/v1/tickets/open，每個 endpoint 綁定明確的 RBAC 角色（agent_support 只能查 ticket，不能查 user）
• 用戶點擊“刪除我的數(shù)據(jù)”后，Agent 不再發(fā)起任何 get_data 請求，且 Server 主動失效其 JWT，并觸發(fā)數(shù)據(jù)庫級 DELETE FROM users WHERE id = ?

他們沒做 fancy 的零信任架構，就靠這兩條，通過了 ISO 27001 認證，客戶續(xù)約率提升 22%。

立即要做的事

• 檢查所有 Supabase 項目：Settings > API > Service Role Key 是否開啟？如果是，立刻關閉
• 在 Supabase SQL 編輯器里運行 SELECT table_name FROM information_schema.tables WHERE table_schema = 'public';，對每張表執(zhí)行 ALTER TABLE xxx ENABLE ROW LEVEL SECURITY;
• 把 MCP Server 的 /mcp/get_data 路由替換成上面示例的白名單+字段過濾版本
• Agent 配置文件里刪掉所有 service_key、admin_token 字段，改用短期 JWT（TTL ≤ 1h）

安全不是加一層抽象，是砍掉所有不必要的通路。MCP 的價值在于連接，但連接的前提是邊界清晰。