Identify the key type before drawing a conclusion
Your frontend needs public project configuration to communicate with Supabase. Treat that configuration as discoverable by visitors. Hiding a variable name, minifying a bundle or removing a source map does not create an access-control boundary.
A publishable key identifies the application component. The signed-in user is identified separately by the user session. Never assume that possessing a public key should confer access to private records.
Check access to data, not just the presence of a key
Consider two apps that publish the same kind of anon key. One allows visitors to read published articles. The other allows visitors to read private order records. The visible key does not distinguish these cases; the permissions and the intended audience do.
A schema exposed through the Data API, a SELECT grant and the applicable RLS policies together determine which rows a role can read. RLS disabled does not by itself prove anonymous access if the role lacks the necessary grants. RLS enabled also does not prove privacy if a policy intentionally or accidentally permits broad reads.
RLS Checker starts with the deployed application URL and tests the anonymous surface it can observe. You do not need to paste a key into the form. If a private table is reported readable, verify its intended audience and fix the access rules. If discovery is partial, investigate the untested surface in your project.
What to do when the exposed key is public
First check that the key really is publishable or a legacy anon key. Then test anonymous access to data that should be private and test isolation between separate signed-in users. Do not use an administrator session to establish what a visitor can access.
Changing a public key alone is not a repair for overly broad access: a replacement used by the browser is public again. Correct the grants and policies, deploy them, and retest. Your app may legitimately require public reads for some tables, so avoid blanket changes that break that behaviour.
What to do when the exposed key is privileged
For a secret or service-role key, remove it from client code and follow the provider’s rotation or revocation procedure. Replace the frontend dependency with a server-side operation that authorises its caller. Check built assets and deployment configuration as well as source files.
Review access logs and the scope of data reachable during the exposure. Removing a file does not revoke credentials already copied. This anonymous table checker is not an exhaustive secret scanner and cannot establish whether a leaked credential was used.