Are Lovable websites secure?

A Lovable website can be secure, but it is not secure merely because Lovable generated it. A static marketing website has a small attack surface; a website with accounts, payments, uploads or private data must also have server-side authorization, protected secrets, correct storage access and tested database policies. Lovable provides security scans and safer backend patterns, but the project owner still has to resolve findings and test access before launch.

How do Lovable and Supabase work together?

Lovable generates the interface and can connect it to Supabase for PostgreSQL data, authentication, file storage, realtime updates and Edge Functions. The Supabase URL and anon key are public by design; Row Level Security policies decide which rows that public client may access. Secrets and privileged operations belong in Edge Functions, never in the frontend.

I can see my Supabase key in the browser. Have I been hacked?

No. The anon key is meant to ship in the browser — every Supabase app has one there. The keys that matter are your OpenAI, Stripe, Resend or service_role keys. Those start with sk_ or are labelled service_role, and none of them should ever appear in a page you serve to the public.

What was CVE-2025-48757?

CVE-2025-48757 describes insufficient Row Level Security in Lovable-generated sites through 15 April 2025 that could allow unauthenticated database reads or writes. The NVD record is marked disputed because Lovable says customers are responsible for protecting their application data. The practical lesson is unchanged: inspect every exposed Supabase table and test its policies instead of treating generated configuration as proof of authorization.

Are Lovable websites and apps secure?

By Defencecore Research · 9 August 2026 · Updated 25 August 2026

Lovable is an AI app builder and AI website builder that can turn a prompt into a working frontend, backend, database and login flow. That speed does not make every Lovable website unsafe, and it does not make every Lovable app production-ready. Security depends on the generated code, the Lovable or Supabase backend configuration, and whether someone tests what an unauthorized user can do before publishing.

Short answer

Lovable websites and apps can be secure, but Lovable cannot make security automatic because access rules depend on what each application considers public, private, administrative or billable. Lovable provides secret storage, Row Level Security tooling and security scans; the owner must still resolve findings and verify authorization before launch.

For a Lovable app connected to Supabase, Row Level Security is the main database boundary. Finding the Supabase anon key in the browser is expected; finding an OpenAI, Stripe or service_role key is a breach, and finding a table that one user can read on behalf of another is an authorization failure.

What the Lovable AI app builder actually builds

The Lovable app builder is not only a mockup generator. It can generate editable application code and connect a frontend to authentication, data, storage and server-side functions. The phrase “Lovable AI website builder” therefore covers two very different products: a public marketing page with no private data, or a full Lovable app with users, payments and an exposed API surface.

Lovable's own security model separates the app into three trust zones: public frontend code in the browser, Edge Functions for private validation and business logic, and a PostgreSQL database protected by Row Level Security. A safe application keeps each decision in the right zone. A hidden button belongs in the frontend; permission to perform the action behind that button does not.

Lovable and Supabase: where security actually lives

The Lovable and Supabase integration gives the generated app PostgreSQL data, authentication, file storage, realtime updates and Edge Functions. The browser receives a Supabase URL and anon key so it can call the API directly. Those two values are public identifiers, not passwords.

The actual database lock is Row Level Security. Supabase recommends enabling RLS on every table in an exposed schema and writing policies for the least access the app needs. That remains true when Lovable generates basic policies for you: test as signed out, as user A and as user B, because “a policy exists” does not prove that user A is unable to read user B's rows.

Lovable now runs a basic security scan before publishing, including RLS linting and database schema review, and offers a deeper on-demand scan. That is a meaningful safety net, but Lovable's documentation also says publishing with unresolved critical findings is still possible unless a workspace blocks it. Treat the scan as a release gate, not as a badge that replaces testing.

1. Check that secrets stayed out of the page

Current Lovable projects have the right mechanism: authenticated APIs use secret storage and server-side Edge Functions. The risk survives in older projects, imported code and manual edits. A secret pasted into a React component or a browser-visible environment variable is compiled into JavaScript served to every visitor.

OpenAI, Stripe, Resend and Twilio keys can spend money or act as your account. A Supabase service_role key is worse: it bypasses Row Level Security by design. None belongs in the frontend, even if the feature works.

The rule is short: if a key can spend money or bypass permissions, it never touches the frontend. It goes in Lovable or Supabase secret storage, and the browser calls an Edge Function instead of the vendor.

60 seconds: is a real key in your bundle?

Open your published app, hit Ctrl/Cmd + Shift + I, go to the Network tab and reload. Click any .js file and search inside it for:

sk-          → OpenAI / Stripe secret key
sk_live_     → Stripe live secret key
service_role → Supabase admin key (bypasses every policy)
re_          → Resend

Any hit means the key is public. Rotate it at the vendor first — that stops the bleeding — then move the call into an Edge Function. Deleting it from Lovable does not un-leak a key that has already shipped.

2. The admin check is in the UI, not the app

You asked for admin-only features. What you usually get is a conditional that hides the admin section unless the logged-in user is you.

That is a visual change. The route still exists, the query still runs, and the endpoint still answers anyone who calls it. Anyone can open the network tab, watch what a request looks like, and replay it with their own account — no tooling, no exploit, just a copied request.

A real check lives somewhere the browser cannot reach: a database policy that scopes rows to the user, or a server-side check inside an Edge Function. If your only defence is that the button is not rendered, you do not have one.

3. Your uploads bucket is public

This one gets missed constantly because nothing about it looks wrong. Supabase Storage buckets can be public or private, and a public bucket serves every file in it to anyone with the URL — no login, no token.

Public is the right setting for avatars and product images. It is the wrong setting for the thing your app probably also stores: ID photos, invoices, CVs, medical forms, anything a user uploaded assuming you would keep it. And the URLs are predictable enough to walk.

Split them. One public bucket for decoration, one private bucket for user files, served through signed URLs that expire. In Supabase this is Storage → your bucket → toggle off Public bucket.

4. Your payment webhook believes anyone

Only relevant if you took the Stripe route, but it is the most expensive item here.

Stripe tells your app about payments by POSTing to an endpoint you expose. That endpoint is public — it has to be. Which means anyone who guesses the URL can POST it too, and if your handler does not verify the signature Stripe sends, it will cheerfully mark an order paid because a stranger said so.

The fix is one call to stripe.webhooks.constructEventwith your webhook signing secret before you trust a single field in the body. Ask for it explicitly — this is not something a "set up payments" prompt reliably gives you.

CVE-2025-48757 and the Row Level Security lesson

You cannot answer “are Lovable apps secure?” without addressing CVE-2025-48757. The NVD record describes insufficient database Row Level Security in Lovable-generated sites through 15 April 2025 that allowed remote, unauthenticated reads or writes. The record is marked disputed: Lovable's position is that each customer is responsible for protecting the data in their application.

The original researcher reported finding more than 170 affected apps. The number is less useful than the failure mode: a public anon key was doing its intended job, while the table behind it had no effective policy. Current Lovable projects have stronger RLS generation and scanning, but any project is unverified until its live policies pass negative-access tests. If you only read one more thing, read how Row Level Security actually fails — including why a broken read policy returns an empty list instead of an error, which is why nobody notices.

Lovable app security checklist before publishing

Run both security scans. Resolve every critical finding instead of publishing through the warning.
Test three identities. Signed-out, user A and user B should each receive only the rows and actions intended for them.
Search the production bundle. No service-role, payment, email or AI-provider secret may appear in downloaded JavaScript.
Review every Edge Function. Require a valid user unless the endpoint is intentionally public, then add a signature or another explicit trust check.
Separate public and private files. Marketing images may be public; documents and user uploads should use private buckets and expiring signed URLs.
Verify payment callbacks.A payment status changes only after the provider's signature is checked server-side.

Then watch it, because you are going to keep prompting

Fixing the four above is a one-afternoon job. Keeping them fixed is not, because you will keep building, and a prompt that adds a feature can quietly move a boundary. These are the changes worth an alert:

A table's protection being switched off — one SQL statement, no visible effect on the app, and the table becomes public.
Login attempts that do not look like your users — the same password tried against hundreds of accounts, or thousands of signups overnight, is visible in Supabase auth logs before anything succeeds.
Your admin key being used from a browser — the observable consequence of a service_role key that made it into the frontend. There is no innocent version of this request.
One endpoint being read over and over with rising offsets — that is somebody downloading a table, and it looks nothing like normal traffic.

Where Defencecore fits

Items 1 to 4 are yours to fix — no monitoring tool can decide that a bucket should have been private. Defencecore covers the part that comes after: it reads your Supabase logs continuously and opens an incident with the evidence attached when a boundary actually moves. It is read-only, so it can explain a problem and never cause one.

Frequently asked questions

Are Lovable websites secure?: A Lovable website can be secure, but it is not secure merely because Lovable generated it. A static marketing website has a small attack surface; a website with accounts, payments, uploads or private data must also have server-side authorization, protected secrets, correct storage access and tested database policies. Lovable provides security scans and safer backend patterns, but the project owner still has to resolve findings and test access before launch.
Are Lovable apps secure?: Lovable apps can be secure when their frontend, Edge Functions and database policies enforce the same rules. The recurring failures are secrets placed in browser code, admin access checked only in the interface, missing or overly broad Row Level Security policies, public private-file buckets and unsigned webhooks. Run Lovable's security scans, then verify the negative cases yourself: one user must not be able to read or change another user's data.
How do Lovable and Supabase work together?: Lovable generates the interface and can connect it to Supabase for PostgreSQL data, authentication, file storage, realtime updates and Edge Functions. The Supabase URL and anon key are public by design; Row Level Security policies decide which rows that public client may access. Secrets and privileged operations belong in Edge Functions, never in the frontend.
I can see my Supabase key in the browser. Have I been hacked?: No. The anon key is meant to ship in the browser — every Supabase app has one there. The keys that matter are your OpenAI, Stripe, Resend or service_role keys. Those start with sk_ or are labelled service_role, and none of them should ever appear in a page you serve to the public.
What was CVE-2025-48757?: CVE-2025-48757 describes insufficient Row Level Security in Lovable-generated sites through 15 April 2025 that could allow unauthenticated database reads or writes. The NVD record is marked disputed because Lovable says customers are responsible for protecting their application data. The practical lesson is unchanged: inspect every exposed Supabase table and test its policies instead of treating generated configuration as proof of authorization.