RowShield
Guides

Inheriting a Supabase project: the first-week audit

Consultants inherit Supabase projects the way surveyors inherit buildings: occupied, load-bearing and undocumented. The previous team knew which table mattered and which policy held the roof up; that knowledge left with them. The first week’s job is reconstruction — map the schema, infer the access model, find where reality diverges from anyone’s intention — before promising changes.

Order matters more than brilliance. A structured audit surfaces the dangerous divergences early, prices them into the engagement, and prevents the classic consultancy wound: discovering an exposed table after your changes get blamed for it. Baseline first, modify second, and put the baseline in writing the client keeps.

RowShield does not detect this yet. This guide gives you the catalog queries to check it yourself. The nine rules that do ship are listed on the rules index.

Map the reachable surface

Begin with what the internet can reach. One query returns every table PostgREST serves with its RLS state and policy count; a second returns buckets with their publicity. Together they answer the opening question that matters: what would a stranger holding the anon key see? Everything else in the audit elaborates this answer.

SELECT n.nspname AS schema_name,
       c.relname AS table_name,
       c.relrowsecurity AS rls_enabled,
       (SELECT count(*)
          FROM pg_catalog.pg_policies p
         WHERE p.schemaname = n.nspname
           AND p.tablename  = c.relname) AS policy_count
FROM pg_catalog.pg_class c
JOIN pg_catalog.pg_namespace n ON n.oid = c.relnamespace
WHERE n.nspname = 'public'
  AND c.relkind IN ('r', 'p')
ORDER BY c.relrowsecurity DESC, c.relname;

Interview the access model

Read the results sceptically. RLS enabled with zero policies means the table serves nothing — occasionally intentional, often a half-finished lockdown that broke a feature somebody papered over elsewhere. Enabled with one blanket-true policy equals disabled with better manners. Flag both for the interview below.

Configuration encodes decisions whose reasons lived in the previous team’s heads. Reconstruct them by asking, for each significant table, who should read and who should write, then comparing the answers against actual policies. Divergence splits into two kinds — accidental looseness to fix, and load-bearing quirks to preserve until understood.

Chase the credentials trail too: where the service key lives, what rotates and when, which integrations hold long-lived tokens. Handover audits die on undocumented integrations — the nightly sync nobody mentioned, holding a key nobody can revoke. List every external consumer of the database before changing anything it might depend upon.

Price and present the findings

Findings become consulting value when priced and ranked: exposure severity, exploitation ease, remediation effort, and the client’s own appetite for risk. A short written baseline — reachable surface, divergences, proposed order of repairs — converts anxiety into a plan the client approves line by line, and protects you when memories differ later.

Deliver the baseline as artifacts the client keeps: the query outputs, the policy inventory, the risk table. Beyond professional courtesy it makes your work comparable — the next auditor diffs against your document rather than starting blind, which is how disciplines improve.

Baseline into watchtower

An audit is a photograph; operations are film. Hand the client continuity rather than heroics: scheduled scanning so the baseline you documented is diffed continuously instead of annually. RowShield does not automate this audit’s judgment — the interviewing, ranking and politics stay human — but it automates the noticing.

Set scan cadence to the engagement — daily on Free, hourly on Indie, every fifteen minutes on Team — and route transition alerts to whoever now owns the system. RowShield reads catalogue and bucket metadata only, never client rows, and is an independent product unaffiliated with Supabase; your successor inherits watchers, not folklore.

Frequently asked

Where should a handover audit start?
With the externally reachable surface — every table and bucket answerable by the anon key. It is a five-minute measurement framing everything after it, and it catches the finding most likely to dominate the engagement: a database that answers strangers politely.
How do we handle policies we cannot explain?
Freeze, do not fix, until explained. A baffling policy is either an accident awaiting deletion or a workaround guarding a real defect; deleting blind risks both. Trace which application paths touch the table, consult the previous team if reachable, then choose between documenting, replacing or removing it.
Should the client keep auditing after handover?
Yes — the engagement ends, the exposure surface does not. Leave monitoring running with alerts routed to the client’s own channel, so drift is caught by machinery rather than by the next consultant’s invoice. Continuity of watching is the cheapest deliverable you can leave behind.

Check your project in about ten seconds

Paste a URL. No signup, no writes, nothing stored.

Run the free audit
supabase audit consultantinherited supabase projecthandover database reviewsupabase security assessment steps