The project ref and the anon key are already in the bundle you ship to browsers, and the anon key is meant to be public [1]. A GET to `https://<project-ref>.supabase.co/rest/v1/profiles?select=*` with that key in both the `apikey` and `Authorization` headers therefore reproduces what an unauthenticated visitor can send, header for header [5]. The request still authenticates. It authenticates as `anon`, and from there the policies are the only thing between the caller and the rows, not the login screen and not the API route [3].
That is why two dashboard-adjacent checks miss the interesting case. `relrowsecurity` on `pg_class` is a boolean, and the source's own query sorts tables by it to find the ones sitting at `false` [12]. False means the policies on that table are inert and the `anon` role reads everything, which is what you get from a table created in the SQL editor that never had the flag set [11]. A `select` policy of `using (true)` leaves the flag true: enabled, has a policy, protects nothing [13]. The shield is answering a smaller question than the one you had. Catching the second case means reading the `qual` column out of `pg_policies` and noticing the word `true` on a table with user data [15]; the form usually intended is `using (auth.uid() = user_id)` scoped `to authenticated` [16]. Two SQL queries to reconstruct what one HTTP response states outright.
Coverage is per command, so a table can hold a careful `select` policy and nothing for `update`, which locks the read and leaves the row editable [17]. The two clauses do different jobs: `using` decides which existing rows a statement may touch, `with check` decides what a row is allowed to look like after an insert or update [18].
The post puts the read check at about ten seconds a table [7]. Three requests a table at that rate is thirty seconds, so a twenty-table schema comes out near ten minutes of curl [21]. That number transfers only if you already have the table list and the key to hand, and it excludes deleting the rows the insert test leaves behind [9].
Note what the clean result actually says. An empty array with a 200 is described as protected and empty for this caller [6], which is narrower than protected. And the evidence here is one practitioner's field pass, with four patterns covering most of what they find [19], not an incidence study. Run it against a project you own: the author is blunt that pointing these commands at someone else's is unauthorized access and a crime in most places [10].
