RLS On Is Not Safe While TRUNCATE Is Granted

The short version

You can enable RLS (Row Level Security), the mechanism that restricts per-row access with policies, write not a single policy, and believe anon / authenticated are locked out — and the table can still be emptied outright if the TRUNCATE privilege remains on it. TRUNCATE is not an operation RLS policies apply to, and Supabase’s default privileges arrive including TRUNCATE unless you explicitly take it away.

What it looks like

There is a table holding a chatbot’s knowledge base (chat_knowledge). Its contents go straight into the LLM’s system prompt, so whoever can write to it decides what the bot says. The intent at design time is written into the table comment.

-- Chatbot knowledge base (RAG)
--
-- ⚠ The contents of this table go straight into the LLM system prompt.
--   Whoever can write here decides what the bot says. Enable RLS and create
--   no policy at all = anon / authenticated can neither read nor write.
--   Only the service role (the server-side API routes) touches it.

Run ENABLE ROW LEVEL SECURITY, write no CREATE POLICY. RLS is deny-by-default, so with zero policies no role passes SELECT or INSERT — that was the design’s reasoning. But while testing against real data on a local Supabase, we noticed anon / authenticated still held the TRUNCATE privilege. The RLS policy count was still zero.

Why

What PostgreSQL’s RLS policies cover is the row-level operations SELECT / INSERT / UPDATE / DELETE; TRUNCATE is not among them. Emptying a table outright is a table-level operation, and the RLS machinery that decides per-row visibility and writability never engages. The only thing decided is whether that role holds the TRUNCATE privilege, which is ordinary table permission (GRANT/REVOKE) territory, independent of RLS.

And this table had TRUNCATE on anon / authenticated despite nobody remembering granting it. Supabase gives roles broad privileges (equivalent to GRANT ALL) by default when a table is created, and with nothing specified TRUNCATE is included. The design’s reasoning — “RLS is on and there are zero policies, so it is safe” — never accounted for the existence of an operation RLS does not reach.

Fixing it

We stripped every privilege on the table from anon / authenticated, and explicitly re-granted only what service_role, the role that actually accesses it, needs.

-- ⚠ Grant privileges explicitly. Relying on Supabase's default privileges
--   (ALTER DEFAULT PRIVILEGES) means they attach or not depending on which role
--   ran the migration. Confirmed on local Supabase 2026-08-16: running from the CLI
--   left service_role without privileges and chat 502'd with
--   permission denied for table chat_knowledge.
-- ⚠ Strip everything from anon / authenticated. Supabase's default is GRANT ALL,
--   so left alone it includes TRUNCATE. **TRUNCATE bypasses RLS**, so
--   "RLS is enabled, therefore safe" does not hold (confirmed locally 2026-08-16).
REVOKE ALL ON public.chat_knowledge FROM anon, authenticated;
GRANT SELECT, INSERT, UPDATE, DELETE ON public.chat_knowledge TO service_role;

REVOKE ALL strips every privilege including TRUNCATE from anon / authenticated, and service_role is explicitly GRANTed only the four operations it needs. The TRUNCATE hole that zeroing out RLS policies cannot close has to be closed on the ordinary privilege side, not in the RLS configuration.

The same commit also fixed a gap on the service_role side. Supabase’s default privileges behave differently depending on which role ran the migration, and in local testing, running from the CLI left service_role without privileges, so chat 502’d with permission denied for table chat_knowledge instead. Since “leave it to the Supabase default” is a foundation that drifts in both directions — too much and too little — we changed policy to state privileges explicitly with GRANT / REVOKE every time.

Preventing a repeat

Enabling RLS with zero policies works correctly for the four operations SELECT / INSERT / UPDATE / DELETE. But concluding from that alone that “this table is locked” is premature: table-level operations such as TRUNCATE, DROP and ALTER TABLE need their privileges checked as a separate category. The more a table has RLS on it, the more readily the assumption “this must be safe now” takes hold, and the more easily the chance to review ordinary GRANT/REVOKE is walked past. On a platform like Supabase where default privileges arrive broad, checking table by table that anon / authenticated hold no unnecessary privileges is a habit worth having, RLS or not.