Supabase table returned a positive anonymous row count
ShipReady confirmed that the named table returned a nonzero count to a bounded request using the public Supabase anon key.
Why it matters
A table intended to be private should not return rows to an anonymous client. Some tables, such as public catalogues or published content, are intentionally readable.
How ShipReady detects it
What it inspects
ShipReady discovers candidate tables from client code, schema information, and a limited common-name list. It sends a bounded HEAD request with the public anon key, a one-row range, and an exact-count preference.
What triggers a finding
The rule triggers when a candidate table returns HTTP 200 or 206 with a positive numeric count in the Content-Range header.
What the evidence shows
The reported table returned a positive row count to the scanner's bounded anonymous probe. The scanner retrieves no row body and does not test writes.
Limits of this check
ShipReady cannot identify why anonymous reading is allowed, whether Row Level Security is disabled or a policy intentionally permits it, which columns are sensitive, or whether all tables were discovered and probed. It does not prove universal database exposure.
How to fix it
Decide whether anonymous reads are intended
Document the public purpose of the table or restrict it with Row Level Security and narrowly scoped policies.
Test as the actual roles
Test anonymous, authenticated, and privileged access using representative queries and least-privilege policies.
How to verify the change
Verify access with an anonymous client
Use a controlled request with the public anon key and confirm a private table no longer returns rows.
Expected: Private tables deny or filter anonymous reads as intended, while intentionally public tables remain documented.