What the free probe checks, and what an empty result means

Anon key only, read-only methods only

The probe discovers a project URL and an anon key by reading your page and up to eight of its JavaScript bundles. The anon key ships to every browser by design, so lifting it from the bundle is not an intrusion; it is precisely where clients get it from.

Method refusal sits in front of every request: anything other than GET, HEAD or OPTIONS is rejected before it leaves the probe. Table checks themselves are GET requests with limit=1, and nothing in the probe can be talked into a POST, PATCH or DELETE.

Address guards run before any socket opens and are re-checked on every redirect hop. Loopback, RFC1918 private ranges, link-local, CGNAT and cloud-metadata addresses are refused outright, so the probe cannot be aimed at internal infrastructure by way of a clever redirect.

Discovery has honest limits: bundle count and size are capped, so a configuration split across many lazily loaded chunks may hide the anon key. The report says when discovery failed and offers manual entry, which is why the audit page accepts a project URL and key directly.

RowShield is an independent product and is not affiliated with or endorsed by Supabase; the probe simply exercises the public endpoints a Supabase project already exposes.

Enumerating tables without credentials

Guessing table names is unnecessary because PostgREST serves an OpenAPI document at the API root listing the tables it exposes. Reading that document is a single request carrying the anon key, and it yields exactly the set of tables the API admits to.

Remote procedure endpoints are skipped; they are functions, not tables. The probe then checks the first fifty of the remaining names and says so when the list was longer. Truncation is recorded in the report rather than hidden, because a partial sweep presented as a full one would be its own kind of dishonesty.

Why an empty array proves nothing

A 200 response containing an empty JSON array is the most misunderstood result in Supabase security. PostgREST answers that way both when Row Level Security filtered every row out and when the table is simply empty, and from the outside the two are indistinguishable.

So the probe refuses to call it a finding. Reachable-but-empty tables are listed in the report under their own status, which keeps the picture complete without putting a fabricated critical in front of you. The finding ANON_TABLE_READABLE is raised only when rows actually came back.

When rows do come back, the probe asks PostgREST for the total visible count via Content-Range, so the finding can say how many rows an anonymous caller can enumerate, along with which columns the first row exposed.

The practical upshot: a profiles table correctly locked down by policy and a log table nobody has written to look identical to the internet, and neither is called a leak.

The two ways the probe can hurt

ANON_TABLE_READABLE means rows were returned to an unauthenticated request carrying only the anon key. The finding names the table, the exposed column names and the row count; the values themselves are discarded before anything is retained, because keeping leaked data in order to tell you about a leak would compound the problem.

SERVICE_ROLE_KEY_EXPOSED means a key that bypasses every policy was found in a client-facing bundle. That key is stored only as a fingerprint, the rotation advice ships inside the finding, and until the rotation happens every other policy in the project is effectively decorative. The fingerprint also lets later scans recognise the same leaked key rather than raising a fresh alarm each run.

What the probe is not

It is not a penetration test and not a substitute for connecting the project. It checks exposure through the front door; write-path gaps, policy logic errors and index health need a connected scan or a person. Treat a clean probe as one door confirmed shut, not as a building surveyed.