Short answer
It can be, but protecting your users’ data is your job, so check it before launch. A 2025 vulnerability record, CVE-2025-48757, describes generated sites whose row-level security let anyone read or write tables; Lovable disputes it, saying each customer is responsible for their app’s data. Either way the checks are the same: row-level security on every table, no secret key in the browser, a test with two accounts, and sign-in checked on the server.
What the record says, and what to check
01
The vulnerability record
“An insufficient database Row-Level Security policy in Lovable through 2025-04-15 allows remote unauthenticated attackers to read or write to arbitrary database tables of generated sites.” NVD, CVE-2025-48757
The US National Vulnerability Database lists CVE-2025-48757 for Lovable through April 15, 2025. Its status there is Deferred. The score shown, 9.3 out of 10 under CVSS 3.1, was supplied by the CVE’s assigner, MITRE, and NVD labels it Secondary, meaning it isn’t NVD’s own score.
02
Lovable disputes it
“NOTE: this is disputed by the Supplier because each individual customer of the Lovable platform accepts a responsibility over protecting the data of their application.” NVD, CVE-2025-48757
The same record notes Lovable’s position: each customer is responsible for protecting their own app’s data. Whichever reading you take, it leads to the same place: check your own app.
03
Row-level security on every table
“Row Level Security decides what this client can reach, so enable it on every table before you deploy.” Supabase, Understanding API keys
Without it, the public key in your app can reach tables that have no rules guarding them. Turn it on for every table, then check the policies themselves, because RLS can be on and still let too much through.
04
No secret key in the browser
“Never use a secret key in the browser or expose it to customers.” Supabase, Row Level Security
The anon or publishable key is meant to be public. The secret or service_role key skips row-level security and has to stay on the server. The free AI app check looks for keys shipped in your site’s JavaScript.
05
Test with two accounts
Sign up as two different users and try to read and change each other’s data, in the app and by calling the API with each user’s session. If either works, a policy is too loose.
06
Check sign-in on the server
Hiding a button isn’t protection. Anything that changes data or costs money, such as payments, admin actions or AI calls, has to check who the user is on the server or in the database, not only in the page.
Checked against the vendor’s docs on : NVD: CVE-2025-48757; Supabase docs: Understanding API keys; Supabase docs: Row Level Security.
Rather hand it over?
Fixed scope, fixed price, paid upfront. The work happens in writing; no call needed.
- from $450AI-Built App RescueA Lovable, Bolt or Cursor app checked end to end in 3 days, then its worst problems fixed at a fixed price.No issues worth fixing, no charge. If the Launch Check finds nothing rated medium or higher, Simon refunds the full $450. You keep the report either way.See scope and start
- from $450App Fix TicketOne reproducible bug in an existing mobile or web app, diagnosed and fixed.See scope and start
Related: Free AI app check · RLS is on: is the data safe now? · Supabase anon key in frontend code · Supabase service_role key exposed · Hire a Lovable developer