From an application URL to an observation
You provide the public HTTPS URL of an application you own or are authorised to assess. The service looks for public Supabase configuration and table references exposed by client resources. Discovery is bounded; it is not a guaranteed inventory of the database.
The worker runs a restricted profile derived from the open-source VICE engine. It performs small anonymous reads and limits network destinations and request budgets. The free checker creates no account and performs no inserts, updates or deletions.
What the report can conclude
A readable sensitive result means that an anonymous read returned a row and potentially sensitive fields were observed. The intended audience and data classification still matter. A likely public result identifies readable data that appears consistent with public content; it is not proof of the owner’s intent.
A blocked result describes a rejected read request. An inconclusive result describes insufficient evidence, including an empty response. Neither establishes that all operations, accounts or resources are safe. Coverage describes the surface observed in that run, not every object in the project.
What this free check does not test
It does not validate account-to-account isolation, write policies, Supabase Storage, all RPCs, Auth settings or server-side code. Tables that are absent from the observable public resources may not be tested. An unavailable API or a discovery failure is not a clean security result.
Project-level RLS testing and authenticated application testing remain separate steps. The practical testing guide explains how to combine those checks without giving the public checker an administrative credential.
Reproducible examples and technical sources
Our SQL fixture demonstrates five permission cases using synthetic integers and a dedicated PostgreSQL visitor role. The documentation test suite executes that fixture in a local PostgreSQL WASM runtime (PGlite) and checks the expected row counts and permission rejection.
This validates the explanations about grants and RLS. It is not a benchmark of production Supabase, an end-to-end network scan or an estimate of how many applications are vulnerable. The fixture and its expected results are available below so you can inspect and reproduce the examples.
Data handling and who maintains the tool
The public report does not return row contents, API key values or sensitive field paths. The exported image summarises the result; review it before choosing to share it. Analytics events use fixed event names and never include the scanned URL, credentials or the scan evidence.
RLS Checker is an independent tool maintained by Webba Creative Technologies and powered by the VICE engine. It is not an official Supabase service. The source links below identify the underlying engine and the provider documentation used to review these explanations.
Reproduce the five local cases
Run only in a disposable local PostgreSQL database. The script creates synthetic data in a transaction, verifies permissions and rolls back its changes. It does not connect to a Supabase project.
Download the SQL fixture