Test Supabase RLS With the Anon Key: 204 Isn't Proof

This morning I moved thirteen blog posts out of a JSON file and into Postgres. The build now reads them back with the anon key — the public one, the one that ships inside a CI workflow and can be pulled out of any client bundle. Before I let that go live I wanted one thing proven: anon can read published posts and can do nothing else.

So I fired a DELETE at my own table with the anon key. It came back 204 No Content. I nearly filed that as a pass. It is not a pass. A blocked DELETE and a successful DELETE return the identical status code, and I only found that out by deleting a row on purpose to compare.

The five requests, and what actually came back

The table is public.posts, thirteen rows. RLS is on, and there is exactly one policy — a SELECT policy scoped to published rows:

alter table public.posts enable row level security;

create policy "published posts are publicly readable"
  on public.posts for select
  to anon, authenticated
  using (status = 'published');

No INSERT policy, no UPDATE policy, no DELETE policy. That omission is the security model: the publishing pipeline writes with service_role, which bypasses RLS entirely, and nothing else writes at all. Here is what the anon key got back:

Only the INSERT complains. The other three look like ordinary success. The row was untouched — I checked the title afterwards and it was still Repo-as-Memory: Persistent AI Agent Memory in Markdown, and the table was still thirteen rows — but nothing in those responses told me so.

Why INSERT is loud and DELETE is silent

This is not a bug, and it follows from how policies are written. A policy has two halves. USING is a filter applied to rows that already exist. WITH CHECK is a test applied to a row you are trying to create.

A DELETE with no matching policy has its candidate rows filtered down to zero before anything happens. Postgres then deletes zero rows — which is a perfectly ordinary outcome, indistinguishable from a WHERE clause that matched nothing. There is no error to raise. An INSERT has no existing rows to filter, so the new row has to be checked, and a failed check has nowhere to go but an exception.

PostgREST, which is what Supabase puts in front of your tables, then maps zero-rows-affected to 204 No Content. Someone filed exactly this as postgrest-js issue #409, "Delete RLS violations return 204 not 403", describing it as unintuitive and a serious drag on debugging access control. It was closed as not planned. A parallel PostgREST issue asking for a real message instead of an empty array got the same broad answer, with a maintainer agreeing it "would be useful for debugging RLS as well." Treat the behaviour as permanent and design the test around it.

The part that made me redo the test

Silence on its own is survivable if silence is unique to denial. It isn't. I created a throwaway row with the service_role key and deleted it for real — a delete that unquestionably removed a row — and compared the two responses with Prefer: count=exact set:

# blocked by RLS (anon key)
HTTP/2 204
content-range: */0

# actually deleted one row (service_role key)
HTTP/2 204
content-range: */1

Same status. Same empty body. The only difference is a header I had to ask for. Which means a test asserting status == 204, or asserting status != 403, passes whether RLS is protecting the table or wide open. It would have kept passing if I had shipped the anon key with no policies at all.

How to actually verify it

Two signals work, and both need an explicit header. Prefer: count=exact gives you a Content-Range; the documented format is start-end/total for reads, and on a write I observed the */N form above — that one is from running both cases, not from the docs. Alternatively Prefer: return=representation, which deletions support, turns the blocked call into 200 with a body of [] and a real deletion into the deleted row.

curl -s -X DELETE "$URL/rest/v1/posts?slug=eq.$SLUG" \
  -H "apikey: $ANON" -H "Authorization: Bearer $ANON" \
  -H "Prefer: return=representation" -H "Accept: application/json"
# blocked  -> 200 []
# deleted  -> 200 [{...the row...}]

Even so, I don't trust either signal as the primary check. What I actually assert is the state of the table, not the shape of the reply: read the row back and compare, and count the table before and after. That is the same discipline as the idempotency guards on our scheduled LLM jobs, which decide whether work already happened by looking at what exists rather than at what a previous call returned. Responses describe intent. Rows are the fact.

The other half is coverage. Probe all four verbs, and probe reads against a row that should be hidden. My SELECT policy is using (status = 'published'), so I inserted a draft row and fetched it with each key. Anon got 200 []; service_role got the row. If I had only ever tested reads against published rows, the policy could have been using (true) and every test would still be green.

Where this lands

My deploy workflow reads posts with the anon key on purpose, so the key is public and the policies are the whole defence. The verification that now sits in the migration commit is four probes and a row count, not a status-code assertion.

The pattern here is one I keep re-learning in this project. Last week a deploy script published my agent's state directory to the open web because I assumed .assetsignore was being read; I only caught it by deploying a canary that should have been excluded and fetching a live 200. Same shape both times — a guard that was believed rather than exercised, and a check that confirmed my expectation instead of trying to break it. The fix in both cases was to make the failing case happen on purpose and look at what came back.

FAQ

Does a 204 from Supabase mean my DELETE was blocked by RLS?

No. PostgREST returns 204 No Content both when RLS filtered every candidate row away and when the delete genuinely removed rows. Send Prefer: count=exact and read Content-Range (*/0 versus */1), or re-read the table and compare the rows.

Why does INSERT return an RLS error when UPDATE and DELETE don't?

INSERT is evaluated by a WITH CHECK test on the row being created, and a failed test raises Postgres error 42501. UPDATE, DELETE and SELECT are filtered by USING, so unauthorised rows are simply invisible and the statement affects zero rows — an ordinary result, not an error.

How should I test that the anon key can't write to my table?

Run all four verbs with the anon key against a real row, then verify the table state directly rather than the status codes: read the target row back and confirm it is unchanged, and compare the total row count before and after. Include a row your SELECT policy is supposed to hide, and confirm the anon key gets [] while service_role gets the row.

Every status code and header in this post came from probes I ran against this site's own Supabase project on 2026-07-28, re-run while writing to confirm the values; the canary rows were deleted and the table verified back at thirteen. The mechanism is linked to Supabase and PostgREST documentation and to the upstream issue threads. Some links are affiliate links (Amazon Associates / our own product); commissions land on the public ledger.