Supabase 安全防坑指南：你的 anon key 其實是透明的

最佳策略，沒有絕對把握不要自己做用戶登錄和收付款。只需要抱大腿。比如在Steam，Apple，微信等平臺發(fā)布產(chǎn)品。

在使用 Supabase 開發(fā)項目時，我發(fā)現(xiàn)很多新手（包括早期的我）都會有一個誤區(qū)：覺得只要把anon key藏在環(huán)境變量里就安全了。

但事實是：你的anon key根本不是秘密。它是發(fā)送給瀏覽器和客戶端的，任何人都能拿到。

Supabase 的安全護(hù)城河不在于隱藏這個 key，而在于你的RLS（行級安全策略）。

今天我整理了一份 Supabase 安全硬化指南，如果你正在用它做小項目，建議對照檢查。

核心風(fēng)險：那把“萬能鑰匙”

Supabase 提供了兩把鑰匙：

1. anonkey：公開的。就像你家大門的把手，誰都能摸到。
2. service_rolekey：超級管理員。它會繞過所有的 RLS 限制。絕對不能暴露在客戶端代碼里！

如果你的數(shù)據(jù)漏了，通常不是因為 key 被盜，而是因為你的 RLS 策略（Row Level Security）根本沒開，或者寫得太松。

常見的幾個“大坑”

在看代碼前，先看看這幾個典型的翻車現(xiàn)場：

• 完全沒開啟 RLS：這是頭號死法。只要沒開，anon角色就能通過 REST API 讀寫所有數(shù)據(jù)。
• 過于寬容的策略：比如FOR SELECT USING (true)，這相當(dāng)于直接把數(shù)據(jù)表公開給全人類。
• 盲目信任客戶端傳來的 User ID：如果你在策略里用user_id = request.body.user_id，黑客只需要改一下請求包里的 ID，就能看別人的數(shù)據(jù)。

在插入任何數(shù)據(jù)前，先執(zhí)行這一句。默認(rèn)情況下，開啟 RLS 但不寫 Policy，意味著“零訪問”。

ALTER TABLE your_table ENABLE ROW LEVEL SECURITY;

永遠(yuǎn)不要相信客戶端發(fā)來的 User ID。Supabase 的 JWT 是經(jīng)過驗證的，用auth.uid()才是防篡改的。

-- ? 安全做法：通過驗證后的 JWT 獲取當(dāng)前用戶 ID
CREATE POLICY "own_data_only" ON notes
  FOR ALL USING (auth.uid() = user_id)
  WITH CHECK (auth.uid() = user_id);

除非你明確需要公開，否則默認(rèn)應(yīng)該拒絕匿名訪問。比如，只允許匿名用戶讀取設(shè)為“公開”的文章：

-- 只允許讀取公開內(nèi)容
CREATE POLICY "public_posts" ON posts
  FOR SELECT USING (is_public = true);

對于復(fù)雜的邏輯，建議寫成 Postgres 函數(shù)并放在服務(wù)端運行。

CREATE FUNCTION get_my_profile()
RETURNS json
LANGUAGE sql
SECURITY DEFINER  -- 以函數(shù)所有者權(quán)限運行，而非調(diào)用者
AS $$
  SELECT row_to_json(profiles) FROM profiles WHERE id = auth.uid();
$$;

即便表鎖死了，如果 Storage Bucket 設(shè)為 Public，里面的文件依然是裸奔的。建議針對文件夾做 RLS：

-- 只允許用戶上傳到自己的文件夾
CREATE POLICY "user_folder_only" ON storage.objects
  FOR INSERT WITH CHECK (
    auth.uid()::text = (storage.foldername(name))[1]
  );

每次項目上線前，我會掃一遍清單：

• 所有表都開啟了 RLS
• 策略里全部使用auth.uid()
• service_rolekey 只存在于服務(wù)端的.env
• .env已經(jīng)加到了.gitignore
• 在 Supabase Dashboard 的 Policy 模擬器里測過anon權(quán)限
• 對敏感表禁用了 Realtime 實時訂閱

記住 Supabase 安全的黃金法則：把你的anon key當(dāng)成完全公開的東西。你的安全模型必須完全建立在 RLS 策略和數(shù)據(jù)庫函數(shù)上。

如果你在做測試項目，最快的安全方案就是：給每張表都開 RLS，但不寫任何 Policy，直到你明確知道哪裡需要開放。

希望這些經(jīng)驗?zāi)軒湍惚荛_數(shù)據(jù)外泄的坑！