RowProof
Production reviews for AI-built apps

Can user B read user A's data?

Apps built with Lovable and other AI tools look finished in the preview. RowProof checks what happens in production: who can read and change each row, whether payments grant and remove access correctly, and whether a stranger can spend your AI budget. In writing. Standard and Advanced prove each finding with live tests.

No passwords, secret keys or production data needed.

Three questions every paid app has to answer

A scanner reads your configuration. A Standard or Advanced review also tests it: two real accounts, your own app client, and a written note of what each one could read or change.

Authorization

Can one user reach another user's rows?

Row Level Security that checks ownership, not just login.

  • Policies, views and SECURITY DEFINER functions
  • Columns users must not edit: plan, role, credits
  • Storage buckets and per-user folders
Billing

Does money match access?

Stripe events decide who has access, not the success page.

  • Webhook signature checked on the raw body
  • Idempotent handling of retried events
  • Cancellations, failed payments and refunds
Cost

Can a stranger spend your AI budget?

Paid model calls stay behind login and per-user limits.

  • Functions that call paid AI APIs
  • Rate limits on public forms and endpoints
  • Keys kept out of the browser bundle

Free: a read-only audit of your database permissions

Paste one query into the Supabase SQL editor (on Lovable Cloud: Cloud, then SQL editor) and run it. It reads only the database catalog and returns a list of findings sorted by severity. It never reads your rows and changes nothing.

Get rls-audit.sql
Tested on PostgreSQL 16.15 against a Supabase-like test database that you can download here: each of the 16 checks fires on its seeded case, and a table with a correct ownership policy returns no finding. The run used a read-only transaction, so any write would have been rejected. Five checks are heuristics and can misfire. Treat each finding as a lead to confirm, not a verdict. It does not cover auth settings, Stripe or your function code.
  • C01RLS off on a table the API can reach
  • C02RLS off, no grants yet (latent)
  • C03Policy that lets every row through
  • C04Policy that also applies to anon
  • C05"Signed in" treated as ownership
  • C06RLS on with no policy at all
  • C07View that bypasses RLS
  • C08Materialized view readable by the API
  • C09SECURITY DEFINER function callable via /rpc
  • C10SECURITY DEFINER without a fixed search_path
  • C11Public storage bucket
  • C12Storage policy without an owner check
  • C13Rows writable in someone else's name
  • C14Personal or secret columns the API can read
  • C15Access decided by user-editable metadata
  • C16Users can edit their own plan or role

What a finding looks like

The script points to the policy. The two-account test proves what it allows. The report gives the fix and the retest.

-- script output
C05  HIGH  public.orders :: "logged in reads"
      SELECT policy only checks that the caller is signed in
      (auth.uid() IS NOT NULL). Any account can reach every row it covers.

-- two-account test, through the app's own client
      user B, signed in, selected orders created by user A  ->  3 rows returned

-- fix and retest
      USING ((select auth.uid()) = user_id)
      user B, same request                                  ->  0 rows

Example from a test database, not from a client.

How a review works

Async and in writing. Scope and a fixed price are agreed before any work starts.

  1. You share what the tier needsStarter: the output of the free script, nothing else. Standard and Advanced: read access to the repository your app syncs to, and a staging URL where I sign up two test accounts with synthetic data. Never passwords, service role keys or Stripe secret keys.
  2. I review and test itStarter: I review the script output and separate confirmed catalog issues from heuristic warnings, with no live tests. Standard: two-account authorization tests on staging. Advanced: Standard plus up to 3 AI endpoints and one Stripe test-mode billing flow.
  3. You get a reportFindings by severity, the evidence for each, and how to fix it. What passed is listed too.
  4. Optional fix sprintFixed price, fixes in a branch, each one proven by the same test that found it.

Questions

Do you need my passwords or keys?

No. Starter needs only the script output. Standard and Advanced need read access to the repository and a staging URL where I sign up my own test accounts. Never send passwords, service role keys or Stripe secret keys.

Is this a penetration test?

No. It is a written review of the areas listed above. It does not cover your infrastructure, third-party services or load, and it is not a guarantee that no other issue exists.

Which stacks?

Supabase and Lovable Cloud (Postgres with Row Level Security), Stripe billing, and serverless functions that call AI APIs.

Do you use AI tools?

Yes. Your code only goes into AI tools where training on my data is turned off: Claude, ChatGPT and Codex. AI helps me read code faster. In Standard and Advanced every finding is confirmed by a live test; Starter findings are labeled as catalog observations or heuristic warnings.

Can I fix it myself?

Yes. Every finding in the report says how. The fix sprint is optional.

Are you affiliated with Lovable, Supabase or Stripe?

No. RowProof is independent.

Get a written review

Buy a fixed-price review on Upwork, from US$ 30, with payment protection for both sides. Send the script output with your first message.

See what you get before you buy: a sample report run on the public test database.

Buy on Upwork