Lovable gets you from an idea to a working, hosted app faster than almost anything else. Speed is the point, and it's also why the unglamorous parts, the settings nobody asks an AI for, tend to be missing when you share the link.
A Lovable app is typically a React single-page app built with Vite, talking straight to a Supabase database from the browser, and published on a lovable.app address or your own domain.
What Lovable gets right
- HTTPS is on by default for published apps.
- There's a built-in place for secrets, and Lovable steers you to it when you paste a key into the chat.
- Supabase's public (anon) key being visible in your code is normal and by design. It only becomes a problem when your database rules are missing.
What Lovable apps usually ship without
- A secret key is baked into your JavaScript filesThird-party keys (OpenAI, Stripe secret, email providers) called from the browser end up inside the JavaScript every visitor downloads.
- No rules about which scripts can run on your siteNo rules about which scripts may run, so one injected script can read everything your users type.
- Clickjacking possible: others can embed your siteNothing stops another site loading your app invisibly and tricking logged-in users into clicking.
- Missing privacy policyA login means you collect personal data. App stores, Stripe and Google sign-in all ask for a policy link.
- Trackers fire before visitors agree to anythingAnalytics added with one prompt usually fires the moment the page opens, before anyone agrees.
- Broken links pretend to be real pagesSingle-page apps answer 'all good' for addresses that don't exist, so search engines index junk.
- Your links look bare when sharedShared links show a bare URL, or Lovable's default preview, instead of your product.
vibeliq checks all of these, and 31 more, from the outside: see every check.
The one that matters most, and no outside scan can see it: your database rules
An outside scan, ours included, reads what a visitor’s browser receives. These live inside your accounts, so they need your eyes:
- Open your Supabase dashboard and go to Database, then Tables (or Table Editor).
- Every table should show row-level security as enabled. A table without it can be read, and usually written, by anyone who has your public key, and that key is in your site's JavaScript by design.
- Enabled isn't enough: open Authentication, then Policies, and read each policy. A policy of 'true' for everyone is the same as no protection. Rows should be limited to their owner, for example where user_id matches the signed-in user.
- Check Storage buckets the same way: a public bucket serves every file in it to anyone with the link.
- Search your project for service_role. That key bypasses every rule and must only exist in server code and server-side secrets, never in the browser.
Questions people ask
Is Lovable itself safe to use?
Yes. The risk isn't the platform, it's what a generated app ships without. In 2025 a published vulnerability (CVE-2025-48757) showed more than 170 Lovable-built apps exposing user data because their Supabase tables had no row-level security. The apps worked perfectly; the rules were simply never written.
My Supabase key is visible in my code. Is that a leak?
The anon (public) key is meant to be visible. The service_role key is not: it bypasses every database rule. If service_role appears anywhere in your browser code, rotate it immediately.
Can vibeliq check my Supabase rules?
No, and be wary of anything that claims to from the outside without your permission. We read what any visitor's browser receives. Your database rules live in your Supabase dashboard, so use the two-minute check on this page.