← 課程地圖

SUPABASE CORE · 114

Public Client Credential / Server Secret:安全邊界不在「把前端 Key 藏起來」

只要 credential 被打包進 Browser JavaScript,使用者就能看到它。前端 credential 的安全模型必須假設它是公開的;真正 privileged secret 才必須只存在可信 server、CI 或管理環境。

Learning outcomes

1. Browser bundle 沒有真正的秘密

const supabase =
  createClient(
    PUBLIC_URL,
    PUBLIC_CLIENT_KEY
  );

Browser 需要使用的資料就能被 DevTools 或 bundle inspection 取得,因此不能把 authorization 建立在「希望 user 不知道 key」。

2. Public credential 的安全模型

public project credential+user session→RLS→limited rows/actions

真正限制資料的是 verified identity + policy / constraint。

3. Privileged credential

能 bypass 一般 user policy、執行管理操作或讀高權限資料的 credential 應留在 server/CI boundary,不應進 Browser、公開 repo 或 client log。

4. Environment variable 不自動等於 Secret

PUBLIC_API_URL
PUBLIC_PROJECT_ID
SERVER_ADMIN_SECRET

敏感性取決於洩漏後能做什麼,而不是它是不是 env var。

5. Threat-model questions

  1. 誰能讀這個 credential?
  2. 它代表 project 還是 specific user?
  3. 它能否 bypass RLS?
  4. 可以旋轉嗎?blast radius 多大?

Project checkpoint:Course Workspace v2

Browser:
  project URL
  public client credential
  user session

Trusted server / CI:
  privileged secret
  migration credential

Database:
  RLS protects user data

Debug evidence

真正應測的是 anon、user A、user B 的資料能力。如果 public credential + user A session 能讀 user B private rows,root cause 在 authorization/RLS,而不是「key 被看到」。

6. Current key model:publishable vs secret

Browser / mobile / desktop
  sb_publishable_...

Trusted backend / worker / Edge Function
  sb_secret_...

目前新 key model 用 publishable key 對應 public client,用 secret key 對應 privileged backend。舊專案仍可能看到 legacy anon / service_role 名稱,但不要因此把 legacy naming 當成安全模型本身。

關鍵:sb_secret_... 與 legacy service_role 都屬高權限 backend credential,能 bypass RLS;不能進 Browser bundle。Public client 的 publishable key 則本來就假設使用者能取得。

錯誤模型:
hide frontend key → safe

正確模型:
public key + verified user identity + RLS
privileged secret stays on trusted backend

Knowledge check

  1. 前端 key 為什麼應假設使用者看得到?
  2. server secret 與 public credential 最大差別?
  3. env var 為何不必然是 secret?
  4. 列一個 credential blast-radius checklist。