Does RowShield get access to my data?

No. Scans read catalog views that describe your schema, and the probe sees only what any internet visitor could already see. Neither path selects row values, so there is nothing data-bearing to protect by hiding.

Does RowShield guarantee my database is secure?

No tool can honestly make that promise, and we do not. Nine specific rules run on every scan; anything outside their reach is described as manual coverage or marked planned, and the pages say so plainly.

Help / Start here

What RowShield does, and what it deliberately does not

All plansLast reviewed 2026-08-23

RowShield is continuous security monitoring for Supabase backends: automated Row Level Security testing, schema-drift detection and an external probe of your deployed app, running on a schedule instead of whenever somebody remembers to open a dashboard.

This page is the version written for evaluators. It covers what the scanner reads, what it never touches, which checks exist today, and exactly where automation stops, because a tool whose edges you cannot see is a tool you cannot trust.

What a connected scan reads

A connected scan opens one Postgres session and runs six fixed statements: five against pg_catalog views that describe your tables, columns, policies and indexes, and one against storage.buckets metadata. A sixth reads the server version string. Catalog views describe structure, not contents.

The scanner never issues a SELECT against one of your tables and never writes anything. Every statement is a module-level constant in the scanner package, exported together as INTROSPECTION_QUERIES, so you can read character for character what will run before you connect anything.

The probe approaches from the outside instead. It loads your app's public pages and JavaScript bundles the way a visitor's browser would, then uses only what is already published there, chiefly the anon key, to test whether tables answer unauthenticated requests.

What it never touches

No scan reads row values, and the probe does not retain them either: when rows come back to an unauthenticated request, the finding records the column names and a count, never the content. An exposed service_role key is stored as a fingerprint, not as the key itself.

Nothing is installed on your infrastructure. There is no agent, no database extension and no write path into your project. We recommend a scanning role whose only ability is reading the catalog, because the engine needs nothing more, and the probe needs no credential beyond the public one.

The same restraint governs what we show back to you. Webhook URLs are masked before they reach the browser, and network failures are mapped to a fixed set of phrases, because driver messages routinely embed internal addresses that have no business on a dashboard.

The nine shipped rules

Seven catalog rules evaluate the schema snapshot: RLS_DISABLED, RLS_TAUTOLOGY, RLS_NO_POLICIES, MISSING_WITH_CHECK, UNINDEXED_RLS_PREDICATE, PUBLIC_BUCKET_EXPOSURE and RLS_UNWRAPPED_AUTH_CALL. Two probe rules test the public surface: ANON_TABLE_READABLE and SERVICE_ROLE_KEY_EXPOSED. Each has a documentation page explaining the detection and its fix.

Nine rules is the entire ceiling of our automated claims, by design. Problem classes that the guides discuss but no shipped rule detects are labelled manual coverage, never implied. When a future rule ships it appears in the rule index with its own documentation; nothing is ever counted as detected that no rule actually looks for.

From scan to alert

Each scan diffs its snapshot against the previous run, and only created, regressed and resolved findings produce alerts. Email is on every plan, Slack arrives from Indie upward, Discord and custom webhooks on Team, and each destination carries its own severity threshold so the right people get the right volume.

A project that stays broken stays quiet; a project that breaks at three in the morning tells someone once, loudly enough to matter, and goes quiet again until something actually changes.

Around the rules

Detection is wrapped in scheduling, transition-only alerting, a health score and remediation SQL generated from your actual columns, plus a command-line interface whose exit codes are chosen for continuous integration. The dashboard shows projects, findings, the health score and a live scan stream; everything it displays derives from the same snapshot-and-diff model the alerts use.

Boundaries worth stating

RowShield is an independent product. It is not affiliated with, and has not been endorsed by, Supabase; Supabase, PostgREST and Postgres are referenced descriptively because they are the systems being checked.

It is also not legal, compliance or audit advice, and it does not deliver certifications. Findings are engineering evidence about a schema at points in time; deciding what to do about them remains yours, and no automated verdict replaces reading the policy yourself.