Is my AI-built app safe to launch?
A working demo is a starting point. Before launch, check who can read and change your data, which credentials reach the browser, and whether access rules hold when someone goes straight to a private page or endpoint. Supabase's production checklist calls for authentication tests, protected API endpoints and database access checks. [1]
Built with Lovable, Bolt, Replit or a similar builder? Start with the checks below. The database steps apply if your app uses Supabase.
Request a free launch-safety check
Send your app URL and email. We answer requests by hand with a short written finding. Nothing is scanned automatically. This is not a certificate of safety.
Check Supabase row level security
Row Level Security, or RLS, controls which database rows a user can access. Table grants control which operations a role can attempt. A table in an exposed schema without RLS can be read or changed by roles with the corresponding grants. Review both the grants and the policies. [2]
Start with tables that hold private user data:
- Confirm RLS is enabled on every table in an exposed schema.
- Check what signed-out visitors and signed-in users are allowed to do.
- Review policies that allow broad access. For example, a SELECT policy using
trueallows all rows for the roles it applies to; that can suit deliberately public data but does not isolate private records by owner. - Check read, insert, update and delete permissions separately. An update policy must also restrict the resulting row, so a user cannot transfer a record to someone else by changing its owner field. [2]
Use test accounts and test records in your own app. Sign in as different users and confirm each can access only the records intended for them. For shared records, check both a member who should have access and a non-member who should not. Supabase documents allow-and-deny database tests for these cases. [2]
What the Lovable CVE does and does not tell you
The public CVE-2025-48757 record describes insufficient RLS in Lovable through April 15, 2025, allowing unauthenticated access to read or write database tables on generated sites. The record is disputed by Lovable: its stated objection is that customers accept responsibility for protecting their applications' data. [4]
That record is not a diagnosis of your app. Use it as a reason to inspect the actual grants and policies, rather than assume the builder's name tells you who can access your data. [2][4]
Tell public API keys from secrets
Finding a Supabase key in browser code does not automatically mean a secret leaked. Supabase distinguishes keys intended for public clients from keys with elevated access. [3]
| Key | Where it belongs | What to check |
|---|---|---|
Publishable key or legacy anon key | Public client code | Review the RLS policies and grants that control access to data. |
Secret key or legacy service_role key | Backend code | Keep it out of browser code. These keys have elevated access and bypass RLS. |
Source: Supabase API key documentation. [3]
Open your browser's developer tools and inspect the code and network requests your app sends. Look for credentials that should stay on the server. Moving a secret into an environment variable is not enough if the value still ends up in the browser's bundle. Supabase treats source code and build artifacts shipped to users as public. [1][3]
If a secret key or service_role key has leaked, follow Supabase's rotation procedure: fix the source of the leak, replace the compromised key, confirm the app uses its replacement, and retire the old key. Removing it from the visible code alone does not revoke it. [3]
Check access beyond the login screen
Try opening a private page directly while logged out. Then test with accounts for each role your app supports, such as a member and an administrator. Confirm that each role sees only what it should. [1]
Also check the endpoints behind those screens. An API key identifies an application component, not an individual user. Supabase recommends using elevated keys only on servers that run their own authorization checks. Do not rely on the browser to decide who may use them. [3]
For each sensitive action, have your developer check that the server verifies the caller and their permission to perform that action. Repeat the request as a signed-out visitor and as a user without that permission, using test data in your own app. This combines Supabase's role-testing guidance with its recommendation to use secret keys only on servers that run their own authorization checks. [1][3]
A short self-check before launch
- Database access: Can you show which roles may read or change each private table, and the tests that enforce it? [2]
- User separation: Have you checked access with different users, including people who must not see a record? [1][2]
- Credentials: Does client code contain only keys intended for public use, with secret keys kept on the backend? [3]
- Private pages and actions: Have you tested direct access while logged out and with a role that lacks permission? [1][3]
Keep a written list of what was checked and patched, and what still needs investigation. Completing this list does not guarantee safety.
Request a free launch-safety check
Unsure what to check next? Send your app URL and email. We review requests by hand and reply with a short written finding.
Need a fuller assessment?
The $500 Production Readiness Audit, credited 100% toward the build. [5]
See the linked page for the full audit scope and terms.
For broader Lovable problems, read our Lovable app troubleshooting guide.
Questions founders ask
Does an exposed Supabase anon key mean my database is exposed?
Not by itself. The legacy anon key is intended for public components, like the newer publishable key. Check the table grants and RLS policies to understand what requests using it can access. [2][3]
Is enabling RLS enough?
You also need policies and grants that match your app's intended access. Test both allowed and denied operations for the relevant users and roles. The switch alone does not demonstrate that private records are isolated correctly. [2]
Does having a login page protect every endpoint?
Check separately. Supabase distinguishes identifying the application from identifying the user, and recommends using secret keys only on servers that run their own authorization checks. Test private pages and role restrictions as well. [1][3]
Is the free launch-safety check an automated scan?
No. You submit your app URL and email, and we reply by hand with a short written finding. Nothing is scanned automatically, and the response does not certify the app for launch.