How to check a Lovable app before launch
A working login and a polished interface are a good start. The next question is what a visitor can reach outside that interface. This walkthrough follows a fictional notes app from a public-file review to a two-account access test.
Which keys belong in public code?
Open your own deployed app and inspect the HTML and JavaScript your browser downloads. A value used by frontend code is visible to visitors, even if its original name was an environment variable. Lovable’s security guidance explains why secrets and authorization decisions belong on the server.
| What you find | What it means | Next check |
|---|---|---|
| Supabase project URL and publishable / legacy anon key | Expected client configuration; presence alone is not a vulnerability. | Review the database permissions and policies behind it. |
| A model-provider secret, payment secret, or privileged database key | Server credentials do not belong in a frontend bundle. | Contain the exposure, move the operation server-side, and follow the provider’s credential-rotation process. |
Before review
Browser → paid AI provider
SERVER_ONLY_CREDENTIALThe browser receives a credential intended for server use.
After a reviewed change
Browser → your backend → provider
The backend authenticates the caller, validates the request and applies usage limits. The credential stays server-side.
Do not paste a live secret into a prompt, feedback form or screenshot. Removing it from the next build does not invalidate copies already downloaded. See our exposed-key guide and Supabase’s key-type and rotation documentation.
Test signed-out, user A and user B
In your test project, create two ordinary accounts and give each an invented note with an unmistakable label: “A-only test note” and “B-only test note.” Record the intended result before you test. Use separate browser profiles so you do not accidentally reuse the same signed-in session.
| Request identity | A’s note | B’s note |
|---|---|---|
| Signed out | No private contents | No private contents |
| User A | Own note available | No private contents |
| User B | No private contents | Own note available |
Check the underlying response as well as the screen. Hiding another user’s note in the interface is insufficient if the response still contains it. Repeat the same allow/deny thinking for edits, deletes, invitations and downloads. For a team app, add a member and non-member from different tenants; a single-owner notes example does not model team membership.
StackSnack’s public URL scan does not sign in as those accounts or prove tenant isolation. Use the Supabase test matrix for the next level of review.
Ask Lovable for a reviewable fix
Describe the intended behavior and ask for a proposed change before applying it. Here is an original prompt for the fictional notes app:
Review my private-notes app in the staging project.
Signed-out requests must not read private notes.
User A must not read or change user B’s notes.
Identify existing grants and all applicable RLS policies.
Propose a migration and allow/deny tests for review.
Do not disable RLS or add broad access to make tests pass.
Keep server credentials out of frontend code and responses.
Explain what the change does not cover.Review the proposed migration against your actual schema. Confirm that normal users still have the access they need and that a broad existing rule is not keeping access open. A prompt is a starting point, not a security assessment.
Publish, repeat the tests and rescan
- Review and test in staging. Keep a versioned migration and a recovery plan. Use artificial records for allow and deny cases.
- Publish the reviewed change. Check the actual deployed build, not only the editor preview.
- Run another authorized website scan. Compare findings, warnings and the checks that actually ran. Keep the private report in its creating browser or export a copy.
- Revisit the account tests. A clean public-file scan cannot establish that authenticated workflows or tenant boundaries are secure.
For deeper website-file checks, add the exact verification tag or file from your StackSnack report and publish it. Database and storage tests require a one-time ownership token published from inside your Supabase project; website verification alone does not authorize them.
Sources and next steps
This walkthrough combines an original fictional example with Lovable’s security guidance and Supabase’s API-key documentation. Continue with the RLS walkthrough or the full launch checklist. StackSnack is independent of Lovable and Supabase.