← Foundations Course

FOUNDATIONS PHASE 2 · 22

Security / RLS：不要相信 Client 說「我是誰」

安全設計先找 trust boundary：哪些 input 可被使用者控制？哪些 identity 已被驗證？哪些規則必須在 server/database 再 enforce？RLS 是把 row authorization 下沉到資料層的一種工具。

Learning outcomes

1. Client Input 永遠可被修改

{
  "owner_id": "admin",
  "score": 999
}

DevTools、curl、script 都能跳過 UI。Server 必須重新驗證資料與 identity。

2. 三個不同問題

Validation:
score 合法嗎？

Authentication:
你是誰？

Authorization:
你能改這筆 course 嗎？

3. Least Privilege

Credential/user/process 只拿完成工作所需最小權限。能用普通 user session 完成的操作，不應拿 privileged admin secret 在 Browser 執行。

4. RLS

courses.owner_id
  =
authenticated_user_id

Row Level Security 可讓 database 依已驗證 identity 決定哪些 rows 能 SELECT/UPDATE/DELETE。

5. RLS 不是資料 Validation

RLS

誰能操作哪列。

Constraint

資料本身是否合法。

Project checkpoint：Course Workspace Trust Map

Browser
  untrusted input
  ↓ HTTPS
Server/Auth
  verified identity
  ↓
Database
  RLS authorization
  constraints integrity

Debug evidence：User A 看到了 User B 資料

  1. request authenticated identity 是誰？
  2. query 是否用了 client supplied owner_id？
  3. RLS 是否 enabled？
  4. policy 是否真的限制 owner？
  5. privileged key 是否誤下放？

Knowledge check

  1. Client validation 為什麼不是 security boundary？
  2. AuthN/AuthZ 差在哪？
  3. Least privilege 是什麼？
  4. score range 應用 RLS 還是 constraint？