Comparisons / Platform-native
RowShield vs the Supabase Security Advisor
The short version
- The Security Advisor is a free dashboard linter that reports common configuration problems at the moment you open it. RowShield is a scheduled monitor that diffs every scan against the last one and alerts on changes between your dashboard visits.
- Choose Supabase Security Advisor when — you want a zero-setup, zero-cost check straight from the vendor, and opening the dashboard when you think about it fits how your project changes.
- Choose RowShield when — your database changes weekly under AI-generated migrations, nobody remembers to re-open the advisor, and you want a regression reported as a regression.
RowShield rules relevant here
- criticalRow Level Security disabled
- criticalPolicy always evaluates to true
- highRLS enabled but no policies
- highWrite policy without WITH CHECK
- mediumRLS predicate column is not indexed
- highStorage bucket is public
- mediumauth.uid() not wrapped in a subquery
- criticalservice_role key shipped to the browser
- criticalTable readable with the anon key
Head to head: Supabase Security Advisor vs RowShield
| Capability | Supabase Security Advisor | RowShield | Edge |
|---|---|---|---|
| When it runs | Runs when someone opens the dashboard page — point-in-time, on demand. | Scheduled scans: daily on Free, hourly on Indie, every 15 minutes on Team. | RowShield |
| RLS-disabled tables in public | Flags RLS switched off in the public schema via its database linter. | Same class of check, every scan, with remediation SQL generated from your columns. | Parity |
| Tautological and missing WITH CHECK policies | Lints always-true policies; write-clause coverage is narrower. | Detects constant-true forms and INSERT/UPDATE policies with no WITH CHECK, per table and role. | RowShield |
| Live behaviour as your anon caller | Does not issue requests — configuration is inspected, not exercised. | The probe reads deployed bundles and asks PostgREST what the anon key can actually fetch. GET only. | RowShield |
| Exposed service_role key detection | Not covered by the advisor. | Scans client bundles for legacy JWTs and sb_secret_/sbp_ formats; stores a fingerprint, never the key. | RowShield |
| Drift and regression detection | No memory between runs — the same warning can appear forever. | Catalog snapshots diffed each scan; findings classified created / resolved / regressed. | RowShield |
| Alerting | Dashboard-only; no Slack, Discord, webhook or email delivery. | Slack Block Kit, Discord embeds, HTML email and generic webhooks with per-destination severity thresholds. | RowShield |
| SECURITY DEFINER views and search_path checks | Ahead here today — the advisor lints definer views and mutable search_path. | Not analysed yet; documented as a known limitation instead of implied coverage. | Supabase Security Advisor |
| Setup and cost | Built into the dashboard. Free, zero setup, no credential sharing. | Free probe needs only a URL; monitoring needs a catalog-read connection string. Paid plans add scheduled monitoring. | Supabase Security Advisor |
Column claims about Supabase Security Advisor are sourced below. Where the edge is theirs, the page says so — and the sections that follow explain why Supabase teams still pick RowShield.
What the Security Advisor does
The advisor ships inside the Supabase dashboard and inspects project configuration against a library of lint checks: row level security switched off in the public schema, policies whose condition is always true, functions with mutable search_path, SECURITY DEFINER views, and a set of auth configuration items such as password requirements and OTP expiry.
It is official, current with the platform, and costs nothing. For a project that rarely changes, running it occasionally and reading the results honestly is a perfectly reasonable posture. Nothing on this page should be read as advice to turn it off.
Where the scopes differ
The three capabilities RowShield sells are configuration posture, live behaviour, and drift over time. The advisor holds the first of those, partially: it reports state at a point in time, from the inside, whenever someone opens the page.
It does not hold behaviour. Whether the anon key can actually read a table is a property PostgREST exhibits on request, and the advisor does not issue requests as your anon caller. RowShield's probe does — GET requests only, using exactly the access a visitor already has — because a policy that deparse-checks as correct can still behave wrongly, and an empty response can mean either "filtered" or "empty".
And it does not hold time. Between two advisor visits there is no record that a policy was rewritten, a bucket flipped to public, or last month's fix quietly reverted. RowShield snapshots the catalog on every scan, diffs, and classifies each change as created, resolved, or regressed. The regression label is deliberate: a problem that returned tells you something about your process that a new problem does not.
Coverage differs in the other direction too. The advisor checks several auth-configuration items and SECURITY DEFINER views that RowShield does not analyse at all. Those are stated plainly in our manifest as not detected rather than buried.
Where the advisor is the right choice
If your schema changes a few times a year and someone on the team genuinely opens the dashboard after each change, the advisor plus discipline is enough, and spending money would be theatre. It also needs no credential sharing at all: the checks run inside Supabase's own infrastructure, which some teams prefer on principle.
For SECURITY DEFINER analysis specifically, the advisor is ahead today, and its findings there are worth acting on regardless of anything RowShield produces.
What RowShield adds for a Supabase backend
Scheduled scans — daily on Free, hourly on Indie, every fifteen minutes on Team — over nine shipped rules spanning RLS state, tautological policies, missing WITH CHECK clauses, unindexed predicates, bare auth.uid() calls, storage exposure, service_role key leakage in deployed bundles, and tables the anon key can actually read.
Findings diff across scans and alerts fire on transitions only, so a project sitting broken pages once instead of hourly. Remediation SQL is generated from your actual column names, always including FORCE ROW LEVEL SECURITY, with one-click copy. A CLI wraps the same engine with CI-safe exit codes, and plans never withhold findings or fixes — limits buy projects and frequency, not truth.
Using both
They compose cleanly, and the honest recommendation for most projects is both: leave the advisor on as the vendor's own checklist, and let RowShield watch the intervals where leaks actually happen. When the two disagree, investigate before dismissing either — the probe tests behaviour the advisor cannot see, and the advisor sees configuration the probe cannot.
RowShield reads pg_catalog metadata only and is an independent product, unaffiliated with Supabase; references to Supabase features here are descriptive.
Frequently asked
- Is RowShield affiliated with Supabase?
- No. RowShield is built by Veristria, an independent company, and is neither endorsed by nor affiliated with Supabase. Supabase and Security Advisor are referenced descriptively and remain trademarks of their owner.
- Can I use both together?
- Yes, and that is the recommended setup. The advisor stays on as the point-in-time vendor checklist; RowShield covers the intervals between visits, where migrations land and fixed things regress.
- Does RowShield replace the advisor?
- No. It replaces the habit of re-opening the advisor. Some checks — SECURITY DEFINER views among them — exist only in the advisor today, and this site documents those gaps rather than implying coverage.
Check your project in about ten seconds
Paste a URL. No signup, no writes, nothing stored.
Run the free audit