IS MY LOVABLE APP SECURE? A BUILDER-FRIENDLY CHECKLIST

This guide is for the builder who shipped a Lovable app over a weekend and is now wondering if it is safe to give to real users. You do not need to read OWASP. You do not need to learn what an SSRF is. You need to run five checks, in this order, before launch.

The order matters. Items 1 and 2 will catch the things that lose every user’s data in a single tweet. Items 3 through 5 catch the things that escalate one user into all users.

1. Enable Row Level Security on every Supabase table

This is the one. Most Lovable security incidents are this.

Open Supabase dashboard, go to Authentication > Policies. For every table in the list:

• If the table holds user data and RLS is off, turn it on now. Your app will break — that is the point. Now write a policy.
• If RLS is on but there are no policies, all access is denied — your app is broken in the safe direction. Add the policy you actually need.
• If RLS is on and there is a policy, read the policy. A policy that says true permits all access; a policy that says auth.uid() = user_id restricts to the row owner.

The most common Lovable mistake is a select policy of true — it lets anyone with the anon key read the whole table. A working policy looks like:

create policy "users can read their own rows"
on public.invoices for select
using (auth.uid() = user_id);

For a hands-off check, use the free Supabase RLS checker — it queries every table from outside using your anon key and reports which ones return rows without auth.

2. Search the deployed bundle for secret keys

In a browser, open your live Lovable URL, then open DevTools and switch to the Sources tab. The deployed JavaScript bundle is everything under your domain. Search the bundle (Cmd+F or Ctrl+F) for these prefixes:

• sk_live_ and sk_test_ — Stripe secret keys (rotate immediately if found)
• rk_live_ — Stripe restricted keys (rotate)
• xoxp- and xoxb- — Slack tokens
• AIza — Google or Firebase service keys
• AKIA and ASIA — AWS access keys
• eyJ followed by Supabase service-role JWT — service-role key

The Supabase anon key (also eyJ…) is meant to ship — that one is fine if RLS is correct (item 1). The service-role key is not — it bypasses RLS entirely.

The free Token Leak Checker loads your URL and runs 100+ key signatures against everything the browser fetched. Use that instead of grepping by hand.

3. Test that one user cannot see another user’s data

Make two test accounts. Log in as user A, copy the URL of one of their resources — an invoice, a project, a profile. Log out, log in as user B. Paste user A’s URL into user B’s browser.

If user B can see user A’s data, you have a BOLA (Broken Object-Level Authorization) bug. This is the second-most-common Lovable issue and it usually shows up in /api/<resource>/:id style routes where the AI filtered by ID but did not check ownership.

Fix: on every read and write that takes an ID, check that auth.uid() owns the row. In RLS terms, add a using clause that joins on the user.

4. Check that role and permission fields cannot be self-edited

If your app has roles — admin, viewer, owner — open DevTools, go to Network, and find the request that updates your profile or account. Edit the request body to include a role: "admin" field, replay it, and reload.

If your account is now an admin, the AI-generated update endpoint is accepting fields it should not. The fix is to either drop the field server-side or restrict the update to a fixed allow-list of safe columns.

5. Confirm the auth callback URL is locked down

Lovable apps using Supabase Auth or third-party OAuth often allow open-redirect on the auth callback — the redirect_to parameter accepts any URL. An attacker can craft a login link that redirects through your domain to theirs and exfiltrate the auth token.

In the Supabase dashboard, go to Authentication > URL Configuration. The Redirect URLs allow-list should contain only your production domain and known dev domains. Wildcards (*) and bare http://localhost in production are red flags.

What this checklist does not cover

The five items catch most of what we find in real Lovable apps but they are not exhaustive. Issues we still see, that this checklist will miss:

• SSRF via user-supplied URLs in upload or import flows
• Verbose error responses that leak stack traces
• Outdated dependencies with known critical CVEs
• CORS allow-all on credentialed endpoints
• Missing rate limits on auth and write endpoints

The full VibeEval scan covers all of those plus 295 more probes. It runs in under 60 seconds against your Lovable URL.

After the checklist

• Run the full VibeEval scan — verifies everything above plus the long tail
• Read the platform-level safety review — context on what Lovable does and does not protect against
• Read the 2026 benchmark — see how your app’s profile compares to 1,500+ others
• Solo founder pre-launch checklist — stack-agnostic version of this list

Related

• Lovable Detector — confirm an app was built with Lovable
• Lovable Password Protection Tester
• Is Lovable Safe? — platform-level review
• Lovable security checklist — full version