Guide Lovable ยท Bolt

How to test your Lovable or Bolt app before real users (no SQL)

By the PatchAndShip team Last verified:

Short answer

You do not need SQL to catch common data leaks before strangers sign up. Make two ordinary test accounts, try your private screens signed out, then try them as the other user. If someone who is not the owner can see or change another person's private rows, stop and fix before real users. Free scans help; they do not replace these clicks. Lovable's security docs say built-in tools "do not replace a thorough security review" and "cannot guarantee complete security."

Prep (about five minutes)

  1. Use fake data only (fake names, emails you control, dummy uploads).
  2. Keep your builder or admin account aside. These tests use two normal user accounts.
  3. Open one private or incognito window for signed-out checks so leftover cookies do not confuse the result.
  4. If you have Lovable's Quick scan or Deep scan, or Bolt's security audit or database Security Audit, run them first and note any open findings. Then do the rituals below on the live or preview URL.

Ritual A: signed out

In a private window, with no account signed in:

  1. Open your app URL.
  2. Try pages that should be private (dashboard, settings, orders, messages, uploads).
  3. Type common admin-style paths directly if you have them (for example /admin, /dashboard, /settings), even when no button shows them.
  4. Write down anything that loads private data without a login.

A login screen or an empty public marketing page is the expected result for private areas. A full private screen with other people's data is a hard stop.

Ritual B: two accounts

  1. Sign up (or use) user A. Create one private item that should belong only to A: a note, order, profile field, upload, or message. Note any id in the address bar.
  2. Sign out fully.
  3. Sign in as user B in the same browser (or a second browser).
  4. From B's session, try to open, edit, or delete A's item. If the URL has an id, change the number or id and try again.
  5. Fail condition: B can see or change A's private data. That means your access rules (Row Level Security policies) or your app logic are too open for real users.

You are not proving every edge case. You are answering one plain question: can another signed-in person reach my private rows the way a curious user might?

Ritual C: light key glance (still no SQL)

On the live site, open the page source or the site's JavaScript files and search for service_role and Stripe sk_live.

  • Seeing your Supabase anon or publishable key in the browser is expected. That key is meant to be public; what it can open depends on your access rules.
  • Seeing a Supabase secret or service_role key, or a Stripe secret key, in browser code is an emergency: rotate that key first, then remove it from the frontend. Related guides cover anon vs secret keys in more detail.

Where this sits next to free scans

Lovable's Quick scan looks for tables without per-record access control, access rules that let everyone through, and leaked-password protection turned off, among other checks. Bolt's project security audit (paid plans) and database Security Audit (all plans) flag open database permissions and related issues; the database audit uses Supabase Advisor-style checks.

Those tools are useful first passes. They do not watch user B click through your real screens with your real data model. Lovable also says that for apps with sensitive data you should consider an additional professional security review. The rituals above are the free behavioral layer you can run yourself.

For longer DIY checklists and Advisor walkthroughs, use the related guides on checking a Supabase app before launch and asking whether your app is leaking data. This page stays the short no-SQL ritual.

What you can DIY vs when to get a second look

You can run the signed-out test, the two-account test, and the light key glance yourself, then re-test after any fix.

Stop guessing if:

  • user B could see user A's data and you are not sure the fix stuck,
  • a scan is clear but you still feel unsafe to launch,
  • you cannot tell, in plain words, whether a database rule means "only the owner" or "everyone."

That feeling is information, not a failure. It is the natural handoff to a read-only second look.

Want a second pair of eyes?

If the two-account and signed-out checks leave you unsure, or you cannot tell whether a database rule means "only the owner," the $49 Database Check is a read-only second look: you run our script and send the results. No passwords, no keys, no login to your account. We change nothing. AI agents run the checks and a human engineer reviews and approves every report. Not a penetration test, a security guarantee or a compliance certification.

See plans and prices

Sources