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

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

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

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

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

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

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

核心風(fēng)險(xiǎn)：那把“萬(wàn)能鑰匙”

Supabase 提供了兩把鑰匙：

1. anonkey：公開(kāi)的。就像你家大門(mén)的把手，誰(shuí)都能摸到。
2. service_rolekey：超級(jí)管理員。它會(huì)繞過(guò)所有的 RLS 限制。絕對(duì)不能暴露在客戶(hù)端代碼里！

如果你的數(shù)據(jù)漏了，通常不是因?yàn)?key 被盜，而是因?yàn)槟愕?RLS 策略（Row Level Security）根本沒(méi)開(kāi)，或者寫(xiě)得太松。

常見(jiàn)的幾個(gè)“大坑”

在看代碼前，先看看這幾個(gè)典型的翻車(chē)現(xiàn)場(chǎng)：

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

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

ALTER TABLE your_table ENABLE ROW LEVEL SECURITY;

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

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

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

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

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

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

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

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

每次項(xiàng)目上線前，我會(huì)掃一遍清單：

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

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

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

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