LovableSecurity:IsYourApptheProblem,orIsLovable?WhichoftheThreeStoriesAppliestoYou

The short version

A headline said Lovable apps leak. Or your publish dialog came back with a critical finding you do not understand. Or a user emailed to say they can see someone else's account. Three different things just happened to three different people, and every page that answers 'is Lovable secure' treats them as one question. They are not.

Here is the short version. There are three separate Lovable security stories. Two of them were user apps with the database policies left off, which is a thing you can check in twenty minutes and fix in an afternoon. One of them, the April 2026 incident, was Lovable's own platform, and it is the only one a certificate or a trust page has anything to say about. A green scan is a floor, not a verdict, and Lovable's own documentation says so in plain words. The key that everyone panics about, the anon key sitting in your bundle, is meant to be there. The one that is an incident is a different key. And almost nothing on this page is a reason to rebuild.

The rest of this page tells you which story is yours, what the scanner actually checked, what it cannot see, what to do in the hour after a real secret leaks, and, honestly, whether you will ever know if someone already read the table. Then it tells you who should close the tab and go back to building.

Is Lovable secure?

The platform, by the usual measures, yes. And that is almost certainly not the question you meant to ask.

Take the platform first, because it is the easy half. In its founder's guide to security, published 24 March 2026, Lovable describes itself as ISO 27001:2022 certified and SOC 2 Type II aligned, with encryption at rest and in transit, a separate Supabase project for every application so tenants are isolated from each other, and no model training on customer data. Lovable Cloud lets you pick a hosting region in the EU, the US or Asia Pacific, and says your data stays there by default. Security issues in the platform go through a HackerOne programme or to a disclosure address. Those are the things an enterprise buyer's questionnaire asks a vendor, and Lovable can answer them.

Now read the scope line on that same disclosure page, because it is the whole point of this article. The programme covers security vulnerabilities in Lovable's own products and infrastructure. Apps built with Lovable are explicitly out of scope and get sent to an abuse form instead. Lovable is telling you, correctly, where its responsibility ends. Your app's tables, the policies on them, the secrets it holds and the checks it runs on the server are not Lovable's products. They are yours, and Lovable's own documentation says the same thing a second way: you are responsible for ensuring the app meets the security requirements appropriate for its use case.

So the honest answer splits in two. Is Lovable, the company and the hosting, run to a standard you would accept from any other vendor? On the evidence they publish, yes. Is the app you built with it secure? Nobody can tell you that from a certificate, because the certificate is about their servers and the question is about your rows. When someone on a sales call answers the second question with the first, they have either misunderstood the question or are hoping you have.

What was the Lovable security vulnerability, and does it apply to an app built today?

There were three, they have different causes, and only one of them applies to a Lovable app built this year without you doing something to reintroduce it.

The first is the one with a CVE number. Matt Palmer, who works in developer relations at Replit, found it on 20 March 2025, reported it to Lovable the next day, got an acknowledgement on 24 March, and published it on 29 May 2025 as CVE-2025-48757 with a CVSS base score of 8.26. His description of the root cause is worth quoting exactly, because every headline since has blurred it: missing or insufficient Row Level Security policies on databases used by Lovable projects, where the generated app makes direct REST API calls against the database from the client using a public and unprivileged anon key. In plain terms, the browser talked straight to the database with a key anyone could read, and the database had no rules about which rows belonged to whom. Superblocks, reporting on the disclosure, attributes a follow-up scan to Palmer that found 303 exposed endpoints across 170 projects. Lovable's response was to ship a security scanner in its 2.0 release in April 2025, one that, again per Superblocks, initially flagged whether Row Level Security was present and not whether it worked.

The second story is February 2026, and it is the same fault line in one app. The Register reported on 27 February 2026 that a researcher, Taimur Khan, examined a single Lovable-hosted application and found sixteen vulnerabilities, six of them critical, with missing Row Level Security and inverted authentication guards at the centre. The app exposed 18,697 user records, 14,928 of them unique email addresses. Lovable's chief information security officer replied that every project gets a free security scan before publishing, that acting on it is at the user's discretion, and that this particular app contained code Lovable did not generate and used a database Lovable did not host. Read that reply carefully. It is a company saying, accurately, this was your app.

The third story is the one that was Lovable's. In its own post of 22 April 2026, Lovable says that between 3 February 2026 and 20 April 2026, the chat history and source code of public projects could potentially be accessed by any Lovable user, because backend regressions in February undid access protections the company had built between March and November 2025. A HackerOne report about it was filed on 22 February 2026 and closed without escalation, in Lovable's words, because its HackerOne partners thought seeing public projects' chats was intended behaviour. A researcher went public on 20 April and Lovable says it shipped a fix within two hours, then made every historically public project private. Lovable does not use the word breach and says private projects and Lovable Cloud were unaffected. The Register's account, published the next day by Jessica Lyons, quotes the researcher's claim that five API calls from a free account reached another user's source code, database credentials, chat history and customer data, and quotes Lovable's initial statement that it did not suffer a data breach. Both accounts are public. You can hold them side by side and decide for yourself what to call it.

Now the question in the heading. Does any of this apply to an app built today? The platform story is closed and was never in your app to begin with, and if your project was public in that window, Lovable says it will contact you. The two app stories are a different matter, because they were never about a date. They were about a table with no rules on it, and Lovable cannot stop you from creating one of those in 2026 any more than it could in 2025. What has changed is the amount of help you get. Lovable's guide says it now enables Row Level Security by default and lints for tables where it is missing. A basic scan has run automatically before every publish since 10 August 2026. Workspace API keys found in public GitHub repositories have been revoked automatically since 25 July 2026. Aikido penetration testing has been available on all plans since 23 June 2026. The floor is much higher than it was. Whether your app is above it is the rest of this page.

What does the Lovable security scan check, and what does a green result mean?

It checks whether the configuration it can see has a known bad shape. Green means it did not find one. That is useful and it is not the same as safe, and Lovable is the first to say so.

There are two scanners, and the difference matters. The Basic scan is what Lovable's documentation calls a fast configuration and dependency check. It lints your Row Level Security policies, reviews the database schema and audits dependencies, and it runs automatically in the background when you open the publish dialog, in about 10 to 15 seconds. It returns one of three results: it passes, it returns warnings, or it flags critical issues, and workspace admins can set critical findings to block publishing until they are resolved. There is an auto-fix mode which, in Lovable's words, resolves straightforward low-risk findings during normal development and makes only non-breaking changes. The Deep scan is a different animal. Lovable calls it a thorough agentic review of your codebase, it takes about two to four minutes, and on top of everything the Basic scan does it reviews access control, backend endpoint protection, exposed secrets, unsafe input handling such as injection and cross-site scripting, insecure storage settings and information leakage. Wiz and Aikido plug in on top of that if you want a third opinion.

Here is what Lovable says the scanners cannot do, quoted rather than paraphrased so nobody can accuse this page of being unfair. The documentation says the tools cannot guarantee complete security and do not replace a thorough security review. The June 2026 post that describes the publish-time scan says the basic scan does not analyse your application code for logic flaws or vulnerabilities unique to how your app is built. And the very first version of the scanner, per Superblocks' reporting on the 2025 disclosure, flagged whether Row Level Security existed and not whether the policy did anything useful. The tool has grown up a lot since then. The category of thing it cannot see has not changed, because no scanner can know that your policy was supposed to say 'only the row owner' when it says 'anyone who is logged in'.

So read a green result the way an engineer reads it. It means: no table the scanner looked at has Row Level Security off, no obviously dangerous schema shape, no dependency with a known advisory, and, on a Deep scan, no secret it recognised in the client code and no endpoint it could tell was unprotected. It does not mean your policies express your business rules. It does not mean the view your dashboard reads from respects those policies. It does not mean the bucket your users upload to is private. Those are the next section, and they are where a founder with a passing scan and a leaking app usually turns out to be standing.

What can a Lovable app still leak after a passing scan?

Five specific things, and each one has a name you can search for in your own Supabase project, because Supabase ships a Security Advisor that runs automatically in the dashboard and reports them as numbered findings.

A view created as postgres. Supabase's Row Level Security documentation says it plainly: views bypass Row Level Security by default, because they are usually created by the postgres user. If Lovable, or you, asked for a handy view that joins profiles to orders so the dashboard loads in one call, that view can read every row of both tables regardless of the policies on them. The advisor reports this as 0010_security_definer_view, and the fix on Postgres 15 and later is to create the view with security_invoker set to true so it runs as the caller.

A policy that lets everyone through. Row Level Security being on is not the same as it being right. A policy written as using (true) for the authenticated role means every logged-in user can read every row the role can reach, and Supabase's documentation says to use that shape only for data that is genuinely public. Generated apps produce this policy constantly, because it makes the demo work and the scanner sees a policy and moves on. Nothing in the tooling can know that your invoices table was not meant to be a shared feed.

An edge function holding the secret key with JWT verification off. Lovable's guide says edge functions are JWT-protected by default, which is true and good. The trap is the one you switched off. Webhooks from Stripe or a payment provider cannot carry your users' tokens, so the function that receives them has to accept unauthenticated calls, and it very often holds the secret key so it can write to the database. That is a public URL with a key that bypasses every policy behind it. It is fine only if the function verifies the webhook signature before it does anything, and our Lovable backend guide covers how edge functions should be shaped for exactly this.

A public bucket that allows listing. Storage has its own policies, on a table called storage.objects, separate from the ones on your data tables. Supabase's storage documentation says public buckets are already publicly accessible, and the advisor's finding 0025_public_bucket_allows_listing flags a public bucket whose policies let a client enumerate everything in it. A bucket of user uploads that is public and listable is a directory of your customers' files with a URL each.

A policy that trusts what the user typed. Finding 0015_rls_references_user_metadata is the advisor's name for a policy that reads a role or a flag out of user_metadata, which the user can edit themselves. A generated admin check that looks at is_admin in the metadata a user controls is an admin panel with a self-service door. Our Lovable authentication guide covers the roles half of this, including which metadata field cannot be edited by the user, so it is not repeated here.

There is a sixth that has no advisor code, because it is not a configuration. It is the April 2026 pattern, in your app instead of Lovable's: an endpoint or a query that takes an id from the request and never checks that the id belongs to the caller. Security people call it broken object level authorisation. Your users call it changing a number in the address bar and seeing someone else's order. A policy on the table catches most of it. An edge function that queries with the secret key and trusts the id in the body catches none of it, and that is the case the scanner explicitly says it does not analyse.

The 20-minute check: is your Lovable app leaking data right now?

You can answer this yourself, today, without a vendor, in the order that finds the worst things first.

Twenty minutes is honest for someone who has seen a Supabase dashboard before. Double it if you have not. Steps one, two and four tell you whether you are exposed right now. Step three tells you whether the policies you have are the policies you meant. Steps five and six are the ones the scanner does not think about. Write down what you found, because the next two sections depend on it.

One thing to hold onto while you do this. Every finding in that list is fixed by editing the app you have: a policy, a view definition, a bucket flag, a function setting, a key moved to Secrets. The hub page on taking a Lovable app to production has the Row Level Security section with worked policies, and the engineer's checklist has the secrets-to-server fix. Neither involves a new codebase.

Your Lovable API key is exposed. What do you do in the next hour?

First work out which key, because one of the two answers is 'nothing, that key is meant to be public', and a lot of panic starts with not knowing that.

Supabase gives every project two classes of key, and it has been renaming them through 2026, so you may see either name. The publishable key, which older projects call anon, is described in Supabase's key documentation as safe to expose online, in a web page, a mobile app, a GitHub action or source code, because anyone can read it and it only reaches what Row Level Security allows. That key is in your bundle by design. It is how the browser talks to the database at all. If a tool, a tweet or a consultant told you your app is compromised because the anon key is visible, the correct response is to check your policies and then stop worrying about the key. The secret key, which older projects call service_role, is the opposite. Supabase's wording is that it provides full access to your project's data, bypassing Row Level Security, that it must never leave your control, and that you must never put it in a browser, a shipped application or source control. Supabase is retiring the old anon and service_role names by the end of 2026 in favour of keys prefixed sb_publishable_ and sb_secret_, which is why step four above searches for both spellings.

If the secret key is in the bundle, the hour looks like this. Rotate it in the Supabase dashboard, which invalidates the old one immediately. Update the value in Lovable's Secrets so the edge functions that legitimately use it keep working, and redeploy them. Then go straight back to the policies, because rotating the key closes the door and Row Level Security decides what was behind it. A secret key in a bundle for a week is only a disaster if the tables behind it had no policies. If they did, the exposure is far smaller than the headline version, and you should know which it was before you decide who to tell.

Third-party keys follow the vendor. A Stripe secret, an OpenAI key or a Maps key in client code gets rotated at that vendor, moved into Lovable's Secrets, and called only from an edge function. Lovable's documentation says it now detects an API key pasted into the chat and steers you to store it in Secrets rather than in code, which closes the most common way these ended up in the bundle in the first place. And a key for your Lovable workspace itself, if it landed in a public GitHub repository, has been revoked automatically since 25 July 2026 through GitHub's notification system, so check your Lovable account for a revocation notice before assuming it is still live.

The order matters more than the speed. People who rotate a secret key and stop there have fixed the symptom. People who rotate it and then write the missing policies have fixed the thing the key was hiding.

Can you tell whether anyone already read your data?

Usually not, and it is better to hear that from this page than from a lawyer later.

Supabase keeps API Gateway logs for every request through its REST and GraphQL layer, and you can filter them by method and by pathname, so a burst of reads against a table you never query from the app is visible if it is still there. The catch is retention. Per Supabase's published plan comparison, logs are kept for one day on the Free plan, seven days on Pro, twenty-eight days on Team and ninety on Enterprise. A table that sat open for six weeks on a Free project has no record of anything older than yesterday. Even on Pro you have a one-week window, and the reads you are worried about happened whenever a scanner or a curious person found the endpoint, which is not on your schedule.

So what you can honestly do is this. Look at the logs you have, for the tables you found open, and see whether there is anything at all. Then decide what you owe your users by the class of data that was reachable, not by the evidence you happen to have kept. If a table with names, emails and addresses was open through the public key with no policies, the defensible assumption is that it could have been read, and the notification rules that apply to you, which depend on where your users are and what the data was, start from that assumption rather than from a clean-looking log. This page is not legal advice and you should get some if the table held anything a regulator cares about. What this page will say is that the retention numbers are the strongest argument on the internet for fixing policies before the launch rather than after the headline, because afterwards you cannot buy the evidence back.

Who does not need to do any of this?

More people than the scanner vendors on this search result would like, and it is worth saying who, so the rest of you know you are not among them.

If your app is an internal tool and its project has workspace visibility, so nobody outside your company can even load it, run the free scan, fix anything critical, and go back to the product. If your app stores nothing you would call personal, takes no payments and holds no uploads, the twenty-minute check is still worth doing once for the habit, and then you are done until the data changes. If you are pre-launch with a handful of test users who are all you, the same. Lovable's checklist before publishing, which runs to seven lines in its documentation, is the right amount of security for that stage, and nobody needs to be paid to walk you through seven lines.

Come back when one of four things is true. Real people you do not know have accounts and the data in those accounts is theirs. Money moves through the app. A user, a customer or an investor has asked the question in this article's title and you could not answer it. Or the twenty-minute check turned up a secret key in the bundle or a second account reading a first account's rows, and the fixes in the hub page are a step past what you are comfortable doing to a live database.

When is a rebuild the honest answer, and when is it being sold to you?

For a security finding, almost never. And the people telling you otherwise usually charge by the rebuild.

Go back through the list of what leaks after a green scan. A view definition. A policy. A function flag. A bucket setting. A key moved into Secrets. Every one of them is an edit inside the application you already have, made by someone who understands Postgres and reads the generated code before touching it. Not one of them requires a new framework, a new hosting provider or a new codebase. The CVE that started all of this was a missing policy, and the fix for a missing policy is a policy. When an agency looks at a scan report and says the whole thing has to be rebuilt in a proper stack to be secure, ask them which of the findings on the report cannot be fixed in place. There will not be one.

There is one situation that genuinely looks like a rebuild and is not a security problem at all. It is the app that never had a server side. Every check lives in the browser, every write goes straight from the client to the table, and there is no place to put a decision the user cannot see. That app has a backend problem, and adding a backend to a Lovable app, through edge functions or a small service beside it, is a known piece of work with a known shape. Our Lovable backend guide covers when that is needed and what it looks like. It is still not a rewrite, and it is still your app at the end.

That is the work we do at Geminate Solutions. We take apps built in Lovable, Bolt, v0 and Replit and get them to the point where real customers can use them, pay through them and trust them, and we do not sell rebuilds. Your Lovable app stays your Lovable app. We have shipped 50+ products, run an EdTech platform at 250,000+ daily users and an exam system absorbing 10 million requests a minute, and hold Top Rated Plus on Upwork at 4.9. You own the code from the first commit. Our AI builder to production service lays out how an engagement runs, our AI code audit guide explains how we read a generated codebase before we change it, and the production checklist for Lovable apps is the hub this page hangs off.

The first step is a written security read of your live app. We do the twenty-minute check properly, read the policies rather than counting them, look at every view, bucket and function, and tell you which of the three stories applies to you, which findings are real, which are noise, and whether anything in there is a reason to rebuild. It almost never is, and we will say so in writing. It comes back within 48 hours and it is yours whether or not we ever speak again.

Frequently Asked Questions

Is Lovable secure?

The platform, by the usual measures, yes. Lovable describes itself as ISO 27001:2022 certified and SOC 2 Type II aligned, runs a HackerOne disclosure programme, hosts regionally, and gives each app its own Supabase project. None of that describes your app. Lovable's own disclosure page scopes its programme to Lovable's products and infrastructure and puts apps built with Lovable out of scope. Your app's security is its row policies, its secrets and its server-side checks, and those are yours.

Was Lovable hacked?

Three different stories get called that. CVE-2025-48757 in May 2025 was user apps with missing Row Level Security, not the platform. The February 2026 report was one user app with 18,697 exposed records, and Lovable said its database was not even hosted by Lovable. The April 2026 incident was the platform: between 3 February and 20 April 2026, chat history and source code of public projects could be read by any Lovable user. Lovable does not call it a breach and says private projects and Lovable Cloud were unaffected.

Does a passing Lovable security scan mean my app is safe?

No, and Lovable says so. Its documentation states the scanners cannot guarantee complete security and do not replace a thorough security review, and that the basic scan does not analyse application code for logic flaws. A pass means the configuration the scanner can see has no known bad shape. A view created as postgres, a policy that grants every row to every user, a public bucket that allows listing, or an edge function with JWT verification switched off can all sit behind a green result.

Is it a problem if my Supabase anon key is visible in my Lovable app?

No. Supabase's own key documentation says the publishable key, still called anon on older projects, is safe to expose in a web page, mobile app or source code, because it only reaches what Row Level Security allows. The key that is an incident is the secret key, still called service_role on older projects, which bypasses Row Level Security and must never be in a browser, a shipped app or source control. If that one is in your bundle, rotate it now.

Do I need to rebuild my Lovable app to make it secure?

Almost never. Every common finding is a row policy, a bucket flag, a secret moved server-side or an edge function setting, all of which are edits inside the app you already have. The one case that looks like a rebuild is an app with no server side at all, where every decision lives in the browser, and that is a backend problem rather than a security one. A security finding used as the reason for a full rewrite is usually being sold, not diagnosed.