Supabase 重大變動：Data API 不再預設公開資料表，開發團隊該如何應對？

問題 5 / 5

現有專案的開發者可以採取哪些策略來提早因應這項變革？

Q: 為什麼 Supabase 決定取消資料表「預設公開」的機制？

Supabase 取消「預設公開」機制主要基於兩大核心理由。首先是為了追求極致的「預設安全」 (Secure by Default)。在舊有的預設設定中，開發者一旦建立新資料表，系統會自動賦予 anon、authenticated 和 service_role 完整的 CRUD（讀寫改刪）權限。雖然這能讓開發者在客戶端立即拉取資料，卻也帶來嚴重的資安隱患。如果開發者在開發過程中忘記設定資料列層級安全 (RLS)，該資料表就會如同「駭客的免費提款機」般完全暴露。隨著 AI 寫碼工具（如 GitHub Copilot、Cursor）與 CLI 自動化腳本的普及，許多資料表是在缺乏人工二次審查的情況下產生的，取消自動公開能從根本上杜絕因疏忽而導致的資安悲劇。其次，這項改變是為了落實「基礎設施代碼化」 (Infrastructure as Code)。未來的存取控制將完全依賴明確的 PostgreSQL GRANT 聲明，這使得權限控管變得可被搜尋 (Greppable) 與可被差異比對 (Diffable)。對於追求嚴謹架構的開發團隊而言，這種做法讓權限變動成為可追蹤的程式碼，是邁向企業級架構的重要一步。透過將「預設方便」轉向「預設安全」，雖然增加了開發初期的手續，但能為產品的長遠生命週期省下無數除錯與防堵漏洞的時間。

Q: 這項更新會影響到哪些開發者？哪些情況則不受影響？

這項更新主要影響的是依賴 Supabase Data API 層進行資料操作的開發者。具體而言，如果你的應用程式符合以下三種情況之一，就必須採取行動：第一，你透過 Data API（包含 PostgREST、GraphQL、supabase-js 或其他官方 Client Library）來讀寫 public 結構下的資料表；第二，你所使用的資料庫遷移腳本 (Migrations) 或部署流程中，在建立資料表時沒有明確寫出 GRANT 聲明；第三，你高度依賴 AI 工具或 CLI 自動建表，且預期這些資料表在建立後能立即被 API 呼叫。在這些情境下，若未手動賦予權限，API 將無法存取新資料。相對地，有些開發情境則「不會」受到此次更新的影響。如果你的後端架構是透過直接連接 PostgreSQL 資料庫的方式運作，例如使用 Prisma、Drizzle 等 ORM 工具，或是透過標準的連接字串直連，這項針對 API 曝光層的調整將不會對你產生作用。此外，Supabase 內建的 storage、auth 與 realtime 等結構的行為將維持不變。最重要的是，這項更新具有針對性，現有專案中已經存在且正在運作的資料表權限不會被更動，因此不會導致現有的線上服務突然中斷，開發者僅需針對「新建立」的資料表進行權限管理調整。

Q: Supabase 針對這項破壞性更新設定了哪些關鍵的時間節點？

Supabase 採取了分段式的溫和退場機制，並明確規劃了三個關鍵的時間節點，讓開發者有足夠的時間進行適應與調整。第一個時間點是 2026 年 4 月 28 日，Supabase 已在建立專案的介面中新增了「是否自動曝光新資料表」的勾選選項，這讓開發者可以在強制執行前，先行手動切換以適應新的安全規範。第二個關鍵日期是 2026 年 5 月 30 日，從這一天起，所有「新建立」的專案都將預設套用新制，新建立的資料表將不再自動對外曝光，開發者必須顯式地宣告權限。最後一個最重要的期限是 2026 年 10 月 30 日，這項規範將強制擴及到「所有現有專案」。在此日期之後，即使是歷史悠久的舊專案，只要是新建的資料表，若缺乏明確的 GRANT 聲明，API 將無法進行存取。儘管如此，Supabase 也給開發者打了強心針：在 2026 年 10 月 30 日之前就已經存在且正常運作中的資料表，其權限設定將保持現狀，不會受到任何更動。這種分階段的實施方式，旨在平衡安全性提升與開發者的遷移負擔，確保所有專案都能在可控的節奏下完成安全升級，迎接更嚴謹的開發時代。

Q: 在新的規範下，開發者建立資料表並希望透過 API 存取時，應遵循哪些步驟？

在未來的開發流程中，建立資料表並使其可透過 API 存取，必須將以下三個步驟視為一個不可分割的整體。首先是「建立明確權限 (Grant)」，開發者必須根據需求，賦予不同角色相對應的權限。例如，若要讓已驗證的使用者具備完整的讀寫權限，需要執行如 grant select, insert, update, delete on public.your_table to authenticated; 的指令。第二步是「啟用 RLS (Row Level Security)」，透過執行 alter table public.your_table enable row level security; 來開啟資料列層級的安全防護，這是確保資料不被非法存取的關鍵門檻。第三步則是「新增存取策略 (Policy)」，開發者需要寫下具體的商業邏輯規則，定義哪些使用者在什麼條件下可以存取特定資料。為了輔助開發者適應此流程，Supabase 優化了錯誤訊息機制。如果開發者忘記進行 GRANT，API 會回傳錯誤代碼 42501，並在訊息中提供具體的修復語法（Hint）。例如，系統會提示：「Grant the required privileges to the current role with: GRANT SELECT ON public.your_table TO anon;」。這種帶有具體引導的錯誤提示，不僅能幫助人類開發者快速除錯，也能讓 AI 代理工具自動判讀錯誤並進行自我修正，大幅降低了從「預設方便」轉向「預設安全」過程中的摩擦力。

AI 根據文章內容回答

對於希望在 2026 年 10 月 30 日強制執行大限前，提早讓現有專案符合高安全標準的開發者，文章提供了兩種具體的應對策略。第一種是手動調整權限規範：開發者可以直接在 Supabase SQL Editor 中執行官方提供的 revoke 語法，撤銷 postgres 角色對於未來物件的預設權限賦予。這項操作的優點在於它不會破壞目前正在運作中的系統功能，但能確保從執行那一刻起，未來在該專案中建立的每一張新資料表，都必須經過嚴格的權限檢驗才能被存取，從而提早建立起安全的開發習慣。第二種策略是利用 AI 工具進行自動化掃描與規劃。開發者可以善用如 Claude Code、Codex、Antigravity 或 Cursor 等 AI 開發工具，並將特定的 Prompt 貼入工具中。該 Prompt 要求 AI 掃描系統中資料庫的使用狀況，並使用 plan mode 分析與規劃 migration 步驟。透過 AI 的協助，開發者可以更全面地檢查現有的資料庫遷移腳本，確保所有的建表流程都已補上必要的 GRANT 聲明。這種做法能將原本繁瑣的手動檢查轉化為自動化的安全稽核，確保專案能無痛接軌到更嚴謹的開發模式。透過這些主動的調整，開發者不僅能避免在最後期限前手忙腳亂，更能藉此機會優化專案的資安防線，確保應用程式的穩固與安全。

其他問題

Q1 為什麼 Supabase 決定取消資料表「預設公開」的機制？ Q2 這項更新會影響到哪些開發者？哪些情況則不受影響？ Q3 Supabase 針對這項破壞性更新設定了哪些關鍵的時間節點？ Q4 在新的規範下，開發者建立資料表並希望透過 API 存取時，應遵循哪些步驟？