Lovable turns a prompt into a working app: a React + Vite + Tailwind frontend, a Supabase Postgres database with auth and storage, and often a Stripe checkout flow, all wired up and deployed in minutes. That speed is genuinely useful. It also means the security defaults are set by a generation step, not by a person reading them line by line.
The uncomfortable truth is that an AI-built app is still just a web app. The browser does not know or care that a model wrote the code. The database does not apply a discount on enforcement because you built it fast. If a table is readable without a login, an attacker reads it — the same as with any hand-written app. So the honest question is not "is Lovable safe," it is "is my Lovable app configured safely right now." Those are different questions, and only the second one matters for your users.
The pattern that has actually bitten Lovable apps
The best-documented failure mode for Lovable-built apps is missing or misconfigured Supabase Row Level Security (RLS). Here is the mechanism in plain English.
Every Lovable app ships a Supabase anon key (now called the publishable key) inside the client bundle. That is by design — Supabase says the publishable key "is safe to use in browsers only if RLS is properly configured." The key is just an identifier. The thing that actually decides who can read which rows is Row Level Security: per-table policies that filter every query against the visitor's identity. With RLS on and policies written correctly, the anon key is effectively powerless — every unauthorized query filters down to nothing. With RLS off, anyone holding that public key can read, and sometimes write, the entire table.
And RLS is not on everywhere by default. Supabase enables it automatically for tables you create through the dashboard Table Editor, but not for tables created from raw SQL. A generation step that builds schema for you can easily produce tables that skip it.
Documented incident
CVE-2025-48757 — CVSS 9.3 Critical
In May 2025, security researcher Matt Palmer published CVE-2025-48757. NVD describes it as: "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." It is rated 9.3 Critical. Palmer's research reported that 303 endpoints across 170 Lovable projects — about 10.3% of the 1,645 he analyzed — had Supabase tables readable by unauthenticated requests using the public anon key, exposing data such as emails, payment details, and API keys.
The honest caveat: Lovable disputes the CVE and states that customers are responsible for securing their own application data. That is a fair position — RLS is a configuration you own, not a bug in the platform. But it cuts both ways: if securing the database is your responsibility, then verifying that you actually did it is your responsibility too. Assuming the generator got it right is not the same as confirming it.
The 5 ways AI-built apps commonly leak
These are the recurring patterns in fast-shipped Lovable, Supabase, and React apps. Each one is checkable, and each maps to something pentes.io looks for on a scan. None of these checks require us to attack your app.
1. Exposed Supabase anon key with missing or weak RLS
What goes wrong: the publishable key is in your bundle (expected) but one or more tables have RLS disabled or have a policy that effectively allows select to everyone. Unauthenticated requests can then read user lists, orders, or messages.
How to check: in the Supabase dashboard, open Authentication → Policies and confirm every table in the public schema shows "RLS enabled" with at least one policy that scopes rows to the authenticated user. A scan flags tables and endpoints that respond to anonymous reads.
How to fix: enable RLS on every public table, then write policies tied to auth.uid() so a row is only visible to its owner. Re-test by querying with only the anon key and confirming you get nothing back.
2. API keys and secrets in the client JS bundle
What goes wrong: a Stripe secret key, a Supabase service_role key, or a third-party API token ends up baked into the frontend build. Anything in the bundle is public. The service_role key in particular bypasses RLS entirely — it is a full-access master key and must never reach the browser.
How to check: view source on your deployed app and search the JavaScript for service_role, sk_live, sk_test, or any token prefix you recognize. A scan inspects served assets for high-entropy strings and known secret formats.
How to fix: move every secret to a server-side context — a Supabase Edge Function or your own backend — and call it from the client. Then rotate any key that was ever exposed, because it should be treated as compromised.
3. Missing security headers (CSP and HSTS)
What goes wrong: without a Content-Security-Policy, a single injected script can run freely, which turns a small XSS into account takeover. Without Strict-Transport-Security, a user can be downgraded to plain HTTP on a hostile network.
How to check: open your site's response headers in your browser's network tab and look for Content-Security-Policy and Strict-Transport-Security. A scan reports which headers are present, missing, or set too permissively.
How to fix: add a CSP that restricts script-src to your own origin and trusted hosts, and send Strict-Transport-Security: max-age=31536000; includeSubDomains on every response. Set these at your host or edge so they apply to the whole app.
4. No rate limiting on open public API routes
What goes wrong: public endpoints — login, password reset, a Supabase Edge Function, a contact form — accept unlimited requests. That invites credential stuffing, scraping, and cost-driving abuse on metered functions.
How to check: identify which routes are reachable without auth and confirm there is a limit per IP or per account. A scan enumerates reachable public endpoints so you can see your real exposed surface; it does not hammer them.
How to fix: put rate limiting in front of public routes at the edge or in your function, and require auth on anything that does not genuinely need to be public.
5. Exposed .env files or production source maps
What goes wrong: a .env served at a public path leaks every secret in it. Production source maps re-expose your unminified source and inline configuration to anyone who opens dev tools.
How to check: request /.env and /.env.production directly and confirm you get a 404, and check whether .map files are served alongside your JS in production. A scan probes for these common exposed-file paths.
How to fix: never deploy .env files to a public directory, disable source-map output for production builds (or restrict it), and keep all real secrets server-side regardless.
Why a generic $5 scanner is not enough here
You can point a cheap, anonymous web scanner at any URL on the internet, and that is exactly the problem. It will scan things you do not own, it does not prove the result belongs to you, and many run intrusive checks that can degrade a live app. For an app with paying users behind it, that is the wrong trade.
pentes.io is built around two constraints that a generic scanner ignores:
Ownership first. A scan never starts until you have cryptographically proven you control the target — either a DNS TXT record or an HTTPS path challenge, ACME-style. That proof is then re-verified inside the scan job itself, so the thing being scanned is provably yours at the moment it runs. No scanning of domains you cannot demonstrate control over.
Non-destructive, always. We run nuclei with the intrusive, exploit, DoS, and fuzzing templates physically removed from the worker image — not just disabled by a flag. OWASP ZAP runs in baseline and passive mode only. testssl.sh runs with no active renegotiation. There is zero chance of knocking over your live app, because the destructive capabilities are not present in the container.
What this is — and is not
An owner-scoped attack-surface monitor, not a penetration test.
To be clear about what you are getting: pentes.io is a monitoring and assessment product. It is not a manual penetration test, and it does not run exploitation modules, proof-of-concept payloads, brute-force attempts, or any agent installed on your infrastructure. An LLM triages the structured findings into a readable report — it reads the scan output, it never touches your systems. If you need an adversarial human pentest for a compliance audit, that is a different and more expensive service. What pentes.io does is give you continuous, honest visibility into your own surface, cheaply enough to run on every deploy.
Free tool
Run a free, non-destructive scan of your Lovable app
Verify ownership with a DNS TXT or HTTPS challenge, then get a triaged report covering missing headers, exposed secrets, reachable endpoints, and TLS configuration — without a single intrusive request.
Where to go deeper
If you want the broader picture beyond Lovable specifically, read our guide to securing AI-generated code, or start from the vibe coders hub for builders shipping with AI tools. Building on a different platform? We also cover Bolt, v0, and Replit (coming soon) — the stacks differ, but the leak patterns rhyme.
Frequently asked questions
Is Lovable safe?
Lovable itself is a legitimate platform, but the apps it generates are only as safe as their configuration. The widely documented failure mode is missing or weak Supabase Row Level Security. In 2025, security researcher Matt Palmer published CVE-2025-48757, rated CVSS 9.3 Critical by NVD, describing how insufficient RLS policies in Lovable-generated projects let unauthenticated attackers read or write arbitrary database tables. Lovable disputes the CVE and says customers are responsible for their own data security. Both things are true at once: the platform can generate a working app in minutes, and the default configuration can leave your database open. That is exactly why you should scan what you shipped instead of assuming it is fine.
How do I secure my Lovable app?
Start with the database. Enable Row Level Security on every table in your public schema and write policies that match your auth model, because the Supabase anon key in your bundle is public by design and RLS is the only thing stopping it from reading everything. Then check the rest of the surface: remove any service_role key or third-party API secret from the client bundle and move it server-side, add CSP and HSTS headers, rate-limit your public API routes, and confirm your .env file and source maps are not served in production. A scan finds which of these apply to your specific deployment so you are not guessing.
Can vibe-coded apps be hacked?
Yes, in the same ways any web app can. A vibe-coded app is a real app: it has a real domain, a real database, and real users. The risk is not that AI writes uniquely bad code, it is that the build process moves fast and the security defaults are easy to skip. The documented Lovable RLS incident is the clearest example, where attackers needed no credentials at all to dump user lists and payment records from misconfigured projects. The fix is the same as for hand-written apps: check the attack surface and close the gaps.
Does scanning my Lovable app risk breaking it?
No. pentes.io is non-destructive by design. We run nuclei with the intrusive, exploit, denial-of-service, and fuzzing templates physically removed from the worker image, OWASP ZAP in baseline and passive mode only, and testssl.sh with no active renegotiation. There are no proof-of-concept payloads, no brute-forcing, and no agent installed on your infrastructure. The scan reads your public attack surface the way an outside observer would, and the scan job will not even start until you have cryptographically proven you own the target.
Built fast, kept honest
Shipping quickly is not the risk — shipping blind is. Once your app is verified and scanned, pentes.io can keep watching it: re-scan on a schedule, show you a diff of what changed between scans, and keep an immutable, append-only audit log of every verification and every finding. That log is not just for you. The day an enterprise buyer, a partner, or an auditor asks "what is your security posture," you have a dated, tamper-evident record to hand them instead of a shrug. Continuous visibility is what turns a weekend project into something you can defend.
Sources. CVE-2025-48757 description, CVSS 9.3 Critical rating, and May 29 2025 publication date: NVD / NIST. Original research and disclosure timeline (303 endpoints across 170 projects, ~10.3% of 1,645 analyzed): Matt Palmer. Supabase publishable/anon key is safe in the browser only with RLS enabled, and RLS defaults: Supabase RLS docs and Supabase API keys docs. Lovable generated stack (React + Vite + Tailwind + Supabase + Stripe): vendor and review coverage as of 2026. Lovable's dispute of the CVE and customer-responsibility position is noted in the NVD record. Specific incident figures are attributed to the cited researcher and should be re-confirmed before publication.