Free scan / Supabase

Is your Supabase app production-ready?

Paste your URL. Get a free automated check in under 60 seconds. Tests RLS enforcement, anon-key exposure, secrets in the bundle, auth flow reachability, and performance before real users arrive.

Definition

A Supabase app is production-ready when row-level security is enabled on every table so the anon key cannot return arbitrary rows, server-side auth is enforced independently of the UI, secrets other than the anon key never appear in client-side code, the app loads over HTTPS in under 2.5 seconds, and payment paths handle errors and webhook replays correctly. Apps built with Lovable, Cursor, or Bolt frequently pass visual testing but fail on the first two: RLS is disabled by default and AI tools often skip enabling it.

Row-level security on every table
The Supabase anon key is public and safe in the frontend. Without RLS enabled on your tables, that key gives any visitor direct read (and sometimes write) access to your entire database via the REST API.
Auth enforced server-side, not just in UI
Hiding a button behind a conditional in your React component does not protect the underlying Supabase query. The API call can be made directly. Auth policies must be enforced at the RLS or Edge Function level.
Secrets kept out of the client bundle
The anon key belongs in the frontend. Your Stripe secret key, OpenAI key, and service-role key do not. AI tools occasionally wire these through NEXT_PUBLIC_ env vars or client components, exposing them in the bundle.
Performance and payment paths
A Supabase app cold-starting a serverless function before every query can add 800ms to 2000ms of latency on first load. Payment paths need to return correct status codes under error conditions or Stripe retry logic breaks.

Run the free scan

Enter your deployed Supabase app URL. The scan checks your live app, not your source code or Supabase dashboard, so deploy first.

What automated checks miss in Supabase apps

The scan covers the surface. These issues require a human running live behavioral tests against your running app.

Cross-tenant data access via ID guessing
An RLS policy that filters by user_id can still expose other users' rows if your API accepts arbitrary IDs in query parameters and the policy relies on a field the caller controls. A static scan cannot reproduce this.
RLS policies that bypass under specific query patterns
A policy that looks correct in the Supabase editor can return unexpected data when queried with a JOIN, a nested select, or an RPC call that the policy author did not anticipate. This only surfaces under targeted live testing.
Auth edge cases under real session state
Token expiry handling, refresh race conditions, and JWT claims that do not match the fields your RLS policies check only surface under real session state with a real user logged in.
Service-role key exposure via server-side leak
The service-role key is server-side only and bypasses all RLS. If it leaks through a misconfigured API route response, a debug endpoint, or an error message, it gives full database access. A static bundle scan will not catch it in a server response.

The pre-launch validation covers all of the above with live behavioral tests against your running Supabase app. Every finding ships with a re-runnable proof and a fix formatted for your AI coding tool.

See what a pre-launch validation covers →
FAQ

Common questions about Supabase production readiness

A Supabase app is production-ready when row-level security is enabled on every table so the anon key cannot read arbitrary data, auth is enforced at the API level and not just in the UI, secrets other than the anon key are kept server-side, the app loads over HTTPS and returns fast initial responses, and payment and webhook paths handle errors correctly. Apps built with Lovable, Cursor, or Bolt often pass visual testing but fail on RLS and server-side auth enforcement.
The scan detects your Supabase project URL and anon key in the page source, then probes the Supabase REST API anonymously to verify RLS is blocking reads. It also checks for other secrets in the client bundle, whether auth entry points are reachable, whether payment paths are live, whether internal links return 200, and whether the initial server response is within an acceptable time.
No, the anon key is designed to be public and is safe to ship to the frontend. The problem is when it is combined with missing RLS: without row-level security, that anon key lets any visitor query your database directly via the REST API. The scan tests both the key presence and whether anonymous REST calls are blocked.
Yes. Lovable generates Supabase-backed React apps quickly, and RLS is the most common gap in the output. Lovable creates the Supabase integration correctly but often ships with RLS disabled on the tables it creates. If you launched a Lovable app without explicitly enabling RLS on every table in the Supabase dashboard, this scan is the fastest way to confirm whether that gap exists.
Passing the automated scan means the surface checks are clear: RLS appears to be blocking anonymous reads, no obvious secrets were found in the bundle, and auth is reachable. It does not cover cross-tenant data access (can user A read user B's rows by guessing an ID?), RLS policy gaps that only appear under specific query patterns, or auth edge cases under real session state. Those require a human running live behavioral tests against your running app.
Go to the Supabase dashboard, open the Table Editor or Authentication tab, and enable Row Level Security on every table. Then add policies that restrict reads and writes to the authenticated user who owns the row. In the Supabase dashboard this is under Authentication, then Policies. Most AI coding tools can write these policies for you if you describe the data ownership model.

Last updated: 2026-06-20