Supabase 在 2026 年 4 月先公告 Data API 的權限預設值將改變，並於 10 月 30 日把新行為套用到既有專案。變更後，由 postgres 角色在 public schema 建立的新資料表，不會再自動把存取權授予 anon、authenticated 與 service_role。若 migration 只建立 table 與 Row Level Security（RLS）policy，卻少了明確的 GRANT，REST 或 GraphQL Data API 會在進入 RLS 判斷前就拒絕請求。

這不是 Supabase Data API 停止服務，也不是既有資料表在 10 月 30 日被全面關閉。官方時程指出，既有物件保留原本的 grants；真正容易出問題的是變更生效後才建立的 table 或 sequence。自架 Supabase 不在官方這次代管平台的套用範圍內，但自架團隊仍應把權限寫進 migration，避免環境之間靠隱含預設值運作。

GRANT、RLS 與 API key 是三個不同關卡

GRANT 決定 PostgreSQL role 是否有權對 table 執行 SELECT、INSERT、UPDATE 或 DELETE；RLS policy 則在角色已有操作權之後，限制哪些資料列可以被看見或修改。前者缺少時，補再多 RLS policy 也不會讓查詢成功。反過來，為了快速修復而把所有權限授予 anon，卻沒有啟用 RLS，也會把原本的功能故障變成資料曝露風險。

API key 只協助請求對應到 anon、authenticated 或其他角色，不會自動創造資料表權限。除錯時應分層記錄：先確認請求使用哪個角色，再查 table 與 sequence grants，最後才檢查 RLS policy 的 USING 與 WITH CHECK 條件。不要看到 401、403 或 PostgREST 錯誤就直接換成 service role key；service role key 不應送到瀏覽器，而且換 key 可能掩蓋錯誤的權限設計。

把建立資料表、授權與 RLS 放在同一個 migration

Supabase 的變更說明建議把三個步驟視為一個單位：建立物件後明確授予必要 privileges、啟用 RLS，再建立 policies。例如公開目錄只需要匿名讀取時，只授予 anon 的 SELECT；會員可新增資料時，再為 authenticated 加上所需的寫入操作。不要照範例一次授予全部 CRUD，而應從實際 API 動作反推最小權限。

若資料表使用 identity 或 sequence 產生主鍵，還要檢查 sequence 的 USAGE 與 SELECT 權限。只修 table grant 可能讓讀取恢復，新增資料仍然失敗。資料庫函式、view、custom schema 也有各自的 grants，不應假設修正 public table 就涵蓋所有 API 路徑。

團隊若使用 Prisma、Drizzle、Supabase CLI 或自製 migration runner，應建立固定模板或 lint 規則。每次新增可由 Data API 存取的 table，都必須同時出現 grants、RLS 與對應 policies；純後端內部表則應明確保持不授權，而不是等待開發者日後補救。由 AI 開發工具產生 SQL 時，也要把這項要求放進專案規範，並由 migration review 與測試驗證，不能只依賴提示詞。

如何盤點 10 月 30 日後的風險

先列出 10 月 30 日後部署的 migrations，以及近期新增的 table、sequence 與 view，再對照前端錯誤、PostgREST 日誌及 Supabase Security Advisor。官方說明指出，Table Editor 的 Data API exposure 標記與 Security Advisor 可協助找出需檢查的表，但仍要回到 migration 檔確認設定可重建，不能只在正式環境用 SQL Editor 手動修好。

測試環境應從空資料庫完整重跑 migrations，而不是複製一個帶有舊 default privileges 的資料庫。驗收至少準備匿名、一般會員、其他會員與後端服務四種身分，逐一測試允許與禁止的讀寫操作。預期被拒絕的案例也要納入測試，否則「全部成功」可能代表權限過寬。

對已經故障的功能，先確認缺少的最小 grants，再以新的 migration 修復。不要修改已經在多個環境執行過的舊 migration，否則新建環境與既有環境可能得到不同結果。修復後重新產生型別或 API schema 時，也要確認快取刷新與部署順序，避免前端先呼叫尚未授權的表。

回滾不等於恢復所有舊預設

官方提供恢復 default privileges 與批次授權既有物件的 SQL，但批次 GRANT ... ON ALL TABLES 可能把原本刻意保持私有的表一併暴露給 Data API。若要回滾，先建立物件清單並標示公開、會員與後端專用範圍，再逐表套用。回滾應是短期維持服務的措施，長期仍應回到顯式權限，因為它能讓程式碼審查清楚看見 API 邊界。

選擇上，小型專案可以先以 Security Advisor 加上 migration checklist 補齊；多環境或代管多租戶專案，則應把 privilege 檢查放進 CI，並在 staging 從零重建驗證。這次變更的核心不是多寫幾行 SQL，而是把「誰可呼叫哪個資料表」從平台的隱含預設，轉成可版本控制、可測試、可回滾的系統契約。