Supabase 2026 年 10 月 30 日變更：新資料表需明確設定 GRANT，附 2 分鐘檢查方法

如果你的應用程式是使用 Lovable、Bolt 或其他以 Supabase 為基礎的 AI 建置工具開發，2026 年 10 月 30 日會有一項變更：新資料表將無法再由你的應用程式存取，除非明確執行 Postgres GRANT 指令。

現有資料表會繼續運作。會出問題的是之後建立的資料表，例如你在 10 月 31 日要求 AI 建置工具加入新功能時建立的資料表。

以下內容均來自 Supabase 自家的更新記錄和文件，並於 2026 年 10 月 28 日查閲。我們尚未在測試專案中實際測試這項變更。

變更內容

一直以來，Supabase 都會在 public 結構描述中的每個新資料表，向 anon、authenticated 和 service_role 角色授予 select、insert、update 和 delete，因此資料表一建立，便可透過 Data API 存取（即 supabase-js 呼叫的 REST/GraphQL 層）。

Supabase 的時間表（更新記錄）：

2026 年 4 月 28 日：建立專案時可選擇啟用
2026 年 5 月 30 日：新專案的預設設定
2026 年 10 月 30 日：對所有現有專案強制執行

根據 Supabase 的説法，以下內容不會改變：現有資料表「保留目前的授權並維持可存取」，資料列層級安全性維持不變，storage/auth/realtime/自訂結構描述不受影響，而只使用直接 Postgres 連線的應用程式也不受影響。

如果你使用 AI 開發應用程式，值得留意 Supabase 提出的原因：Agent、CLI 指令碼和 AI 平台現在會在沒有人檢查差異的情況下建立資料表，而舊有預設設定令資料表在尚未設定安全措施前便容易暴露。

會受影響的用戶

Supabase 表示，如果你的應用程式透過 Data API 存取 public 資料表（supabase-js、任何客戶端程式庫、/rest/v1/、/graphql/v1），或者你的遷移或 AI 編碼工具建立資料表時沒有加入 GRANT 陳述式，就需要採取行動。

大部分以 AI 開發的 Supabase 應用程式都屬於這種情況：瀏覽器直接呼叫 …supabase.co/rest/v1/，而 AI 則撰寫遷移。在我們於 2026 年 10 月 16 日進行的測試中，Lovable 的應用程式使用 Lovable Cloud（兼容 Supabase），而 Bolt 的應用程式則使用 Bolt Database（Supabase）。

未經證實：這些代管後端是否會在同一天套用這項變更，以及 Lovable 或 Bolt 是否已代你加入授權。如果你連接的是自己的 Supabase 專案，請假設這項變更適用於你的專案。

如何判斷（2 分鐘快速檢查）

症狀：使用新資料表的功能無法載入或儲存資料，但舊有功能正常。Supabase 的疑難排解文件指出，客戶端通常會回報 401 或 403。
瀏覽器：DevTools → Network → 點選失敗的請求，以查看 …supabase.co/rest/v1/<table>。缺少授權時會顯示如下內容：

{
  "code": "42501",
  "message": "permission denied for table your_table",
  "hint": "Grant the required privileges to the current role with: GRANT SELECT ON public.your_table TO anon;"
}

hint 會指出角色，以及缺少的確切 GRANT。

不要與 RLS 錯誤混淆。代碼同樣是 42501，但如果訊息是「新資料列違反資料列層級安全性政策」，代表資料列層級安全性政策正在正常發揮作用，並非這項變更所致。在 Lovable 和 Bolt 的應用程式中，我們也見過完全相同的情況：第二位用戶嘗試以第一位用戶的身分寫入資料列。
Supabase 控制台：Supabase 表示，Security Advisor 會標示受影響的資料表（並提供修正用的 SQL），而 Table Editor 會顯示 Data API 暴露標記。如要在 SQL Editor 查看資料表的授權：

select grantee, privilege_type
from information_schema.role_table_grants
where table_name = 'your_table';

修正方法：使用 GRANT，並保持 RLS 啟用

Supabase 表示，應在同一個遷移中將兩者視為一個整體：「如果缺少授權，Postgres 會在 RLS 生效前拒絕查詢。」

-- 1. Grant only what each role needs
grant select on public.your_table to anon;  -- only if logged-out visitors should read it
grant select, insert, update, delete on public.your_table to authenticated;
grant select, insert, update, delete on public.your_table to service_role;

-- 2. Keep row level security on
alter table public.your_table enable row level security;

-- 3. Add the policies you need
create policy "users can read their own rows"
  on public.your_table
  for select
  to authenticated
  using (auth.uid() = user_id);

以下三件事應避免：

不加思索地授予 anon。除非資料表本來就是供公眾存取，否則不要加入這項授權。
把授權當作安全防護。Supabase 的文件指出：授權決定某個角色能否存取資料表，RLS 則決定可存取哪些資料列。未啟用 RLS 的資料表，任何獲授相應權限的角色都可存取，而 anon 是你的公開金鑰。
一次過向整個 schema 授權。這也會開放任何從未啟用 RLS 的資料表。

給 Lovable、Bolt 或你的程式編寫 Agent 使用的提示詞

我們撰寫的示例，並非經測試的做法：

從現在起，每次你在 Supabase 的 public schema 建立新資料表，都要在同一個 migration 中加入明確的 GRANT 陳述式，並建立資料表、啟用列級安全性及設定其政策。只在應用程式需要的地方，向 authenticated 和 service_role 授予 select、insert、update 和 delete 權限。只有預期供已登出的訪客讀取的資料表，才向 anon 授予 select 權限。絕不要關閉列級安全性，也不要一次過向 schema 中的所有資料表授權。現在檢查資料表 [your_table]；它會傳回錯誤 42501 "permission denied for table"：加入缺少的授權，保持 RLS 啟用，並列出你新增的授權和政策。

然後在開啟 Network 分頁的情況下重新載入，確認 42501 已消失。Supabase 亦建議更新 AI 工具的系統提示詞，或使用其 Agent skill，讓授權預設自動加入。

來源

附有證據標籤的完整指南：Supabase 10 月 30 日的變更：新資料表需要 GRANT。相關內容：雙帳戶測試（用戶 A 能否查看用戶 B 的資料？）。

利益披露：我們營運 VibeTierList，測試 AI 應用程式建置工具。想找人為你的上線中應用程式進行這類檢查？Launch Check，$29。這項服務與我們的排名無關：你的應用程式不會被納入排名，而付款絕不會影響任何工具的評分。Supabase 沒有向我們付款。