---
title: "Lovable app security issues: an afternoon checklist | Zeroic"
description: "Lovable app security issues trace back to six settings: keys, RLS, policies, storage, Edge Functions and rate limits. Check all six before your launch."
url: https://zeroic.in/blog/lovable-app-security-issues
---

[The Zeroic Journal](https://zeroic.in/blog)

[Software engineering](https://zeroic.in/blog/topic/software-engineering) October 14, 2026 8 min read

# Lovable app security issues: an afternoon checklist

Lovable's built-in scan reports only critical findings. These are the six settings behind most leaks, and how to check each one yourself.

By Khushi Arora Partner @ Zeroic

On this page

1. [Lovable app security issues start in the browser](#lovable-app-security-issues-start-in-the-browser)
2. [Row level security decides who reads what](#row-level-security-decides-who-reads-what)
3. [Storage buckets and Edge Functions leak quietly](#storage-buckets-and-edge-functions-leak-quietly)
4. [Rate limits stop at Supabase Auth](#rate-limits-stop-at-supabase-auth)
5. [Lovable’s security scan is a floor](#lovables-security-scan-is-a-floor)
6. [The afternoon checklist](#the-afternoon-checklist)
7. [Sam’s List, VoiceDrop and 100+ audits: what we check first](#sams-list-voicedrop-and-100-audits-what-we-check-first)

On this page 7 sections

1. [Lovable app security issues start in the browser](#lovable-app-security-issues-start-in-the-browser)
2. [Row level security decides who reads what](#row-level-security-decides-who-reads-what)
3. [Storage buckets and Edge Functions leak quietly](#storage-buckets-and-edge-functions-leak-quietly)
4. [Rate limits stop at Supabase Auth](#rate-limits-stop-at-supabase-auth)
5. [Lovable’s security scan is a floor](#lovables-security-scan-is-a-floor)
6. [The afternoon checklist](#the-afternoon-checklist)
7. [Sam’s List, VoiceDrop and 100+ audits: what we check first](#sams-list-voicedrop-and-100-audits-what-we-check-first)

Lovable app security issues come down to six settings: a secret key in the browser bundle, tables with row level security off, policies that let everyone through, public storage buckets, Edge Functions with JWT checks turned off, and no limits on paid actions. UpGuard found 16,326 Supabase databases with readable tables. You can check all six in an afternoon.

None of these are exotic. They’re defaults nobody changed and shortcuts taken to clear an error during development. The scale is what makes them urgent: in its [study of exposed Supabase apps](https://www.upguard.com/blog/everything-everywhere-systemic-data-exposure-in-supabase-apps), UpGuard checked about 300,000 domains, found 16,326 databases with readable tables, and reported that over half of them held some personal data. It also explains why apps built by coding agents get hit: Supabase turns RLS on for tables made in the dashboard, but tables created through the API, which is how agents work, don’t get it by default.

Lovable’s own scan won’t close that gap for you. Its [security overview](https://docs.lovable.dev/features/security) says the tools “cannot guarantee complete security” and that you are responsible for meeting your app’s security requirements. Take that at its word and check the settings yourself.

## Lovable app security issues start in the browser

Everything your app ships to the browser is public. That’s fine for the publishable key (the legacy `anon` key): Supabase’s [guide to API keys](https://supabase.com/docs/guides/getting-started/api-keys) calls it safe to expose, because it only reaches what row level security allows. It’s a disaster for a secret key. The same guide says a secret key “bypasses every Row Level Security policy you have” and must never go in a browser, a shipped app or source control.

Secrets reach the browser in two common ways:

- **A `VITE_` variable.** If your project has a `vite.config` file, it’s built with Vite, and the [Vite env docs](https://vite.dev/guide/env-and-mode) say any variable prefixed with `VITE_` is bundled into client-side code at build time. A `VITE_SUPABASE_SERVICE_ROLE_KEY` or `VITE_OPENAI_API_KEY` is readable by anyone who opens your site.
- **A key pasted into a component** to make a failing call work. The call works, and the key ships.

This isn’t hypothetical. Escape scanned over 5,600 public vibe-coded apps, about 4,000 of them on Lovable, and its [write-up of the method](https://escape.tech/blog/methodology-how-we-discovered-vulnerabilities-apps-built-with-vibe-coding/) reports more than 400 exposed secrets, noting that Supabase service keys “were often trivially retrievable from frontend bundles”.

**Check:** open your live site, open the browser’s developer tools, and search all loaded JavaScript for `service_role`, `sb_secret_`, `sk_live` and `sk-`. Search your Git history for the same strings.

**Fix:** rotate any key you find, then move the call into an Edge Function that reads the key from Lovable’s Secrets. Lovable’s docs are blunt that API keys “cannot be stored safely in client-side code.”

## Row level security decides who reads what

The publishable key is only safe if every table it can reach is locked down. Supabase’s [row level security guide](https://supabase.com/docs/guides/database/postgres/row-level-security) states that a table in an exposed schema without RLS is readable and writable by any role with a grant on it. Turning RLS on is step one. The policies are step two, and that’s where Lovable apps leak most.

The history here is instructive. When Matt Palmer scanned Lovable projects in 2025, he found [303 vulnerable endpoints across 170 projects](https://mattpalmer.io/posts/2025/05/statement-on-CVE-2025-48757/), about 10.3% of the 1,645 he analyzed. His statement also notes that the security scanner Lovable shipped afterward “merely checks for the existence of any RLS policy, not its correctness or alignment with application logic.” A policy of `using (true)` passes an existence check and still hands every row to every visitor.

**Check, part one:** open the Security Advisor in your Supabase dashboard, or run `supabase db advisors` from the CLI. The [Advisors docs](https://supabase.com/docs/guides/observability/advisors) list the lints that matter most here:

- `0013_rls_disabled_in_public` (ERROR): a table anyone with your project URL can read, edit and delete.
- `0024_permissive_rls_policy` (WARN): a policy that allows unrestricted access.
- `0010_security_definer_view` (ERROR): a view that bypasses row level security.
- `0002_auth_users_exposed` (ERROR): user data exposed through a view.

**Check, part two:** the advisor can’t tell whether a policy matches your business rules. Create two test accounts. Sign in as the second one and try to read, edit and delete records that belong to the first, through the app and through the REST API with the second user’s token. Anything that succeeds is a leak.

If the policies themselves misbehave, our breakdown of [why Supabase RLS stops working](https://zeroic.in/blog/supabase-row-level-security-not-working) walks through the six causes and their fixes.

## Storage buckets and Edge Functions leak quietly

Two more settings don’t show up when you look at your tables.

**Public storage buckets.** Supabase’s [storage bucket docs](https://supabase.com/docs/guides/storage/buckets/fundamentals) say a public bucket bypasses access controls for retrieving and serving its files. That’s right for logos and marketing images. It’s wrong for ID documents, invoices or anything a user uploads privately. Private buckets enforce RLS on every operation and serve files through signed URLs. Make every bucket that holds user files private, and watch for the `0025_public_bucket_allows_listing` lint, which flags buckets whose contents anyone can list.

**Edge Functions with JWT checks off.** By default, the platform checks the caller’s token before your function runs. The [Edge Functions auth docs](https://supabase.com/docs/guides/functions/auth) warn that turning `verify_jwt` off “to clear a 401 during development removes the platform’s check.” That’s exactly the shortcut an AI builder takes when a function throws an auth error. Search `supabase/config.toml` for `verify_jwt = false`. Every function on that list either needs to be public on purpose, like a webhook that verifies its own signature, or needs the check back on.

## Rate limits stop at Supabase Auth

Supabase rate-limits its Auth endpoints out of the box. The [Auth rate limit docs](https://supabase.com/docs/guides/auth/rate-limits) list defaults such as 2 emails per hour from the built-in email provider and 30 requests per 5 minutes on sign-up, recovery and one-time-code endpoints. The page lists nothing for database queries or Edge Function calls, and Lovable’s security overview doesn’t mention rate limiting at all.

So every function you wrote is unlimited until you limit it. That matters most where each call costs money. OWASP’s guidance on [unrestricted resource consumption](https://api-security.owasp.org/editions/2023/en/0xa4-unrestricted-resource-consumption) names resources paid per request, such as email, SMS and phone calls, and recommends spending limits on every provider, or billing alerts where limits aren’t available. A script hitting your “generate summary” function in a loop runs up your AI bill, and one hitting your “send invite” function burns your SMS credit.

**Fix:** add a per-user limit to every function that calls a paid API, sends a message or charges a card, and set a hard monthly cap in the OpenAI, Twilio or email provider dashboard today.

## Lovable’s security scan is a floor

Lovable has invested in security tooling, and you should use it. Its [security overview](https://docs.lovable.dev/features/security) describes two scans. The quick scan runs a fixed set of checks on every publish: tables without per-record access control, rules that let everyone through, storage rules, dependencies. The deep scan reviews all your code for issues in your app’s logic, permissions and data.

Read the limits as carefully as the features:

- The deep scan “does not run automatically as you work.” Run it yourself before launch and after big changes.
- “Only vulnerabilities rated critical become findings.” A high-severity issue can sit there with no finding.
- The tools “do not replace a thorough security review,” in Lovable’s own words.

A clean scan tells you the obvious holes are closed. It doesn’t tell you a user can’t read another user’s orders. That’s what the two-account test is for.

## The afternoon checklist

Run these in order. The first three can leak data today; the last three cost money or leak it under specific conditions.

#CheckWherePasses when

1No secret keys in the bundleBrowser dev tools, Git historyNo `service_role`, `sb_secret_`, `sk_live` or `sk-` strings anywhere

2RLS on every exposed tableSupabase Security AdvisorNo `0013` or `0010` errors

3Policies match your rulesTwo test accountsUser B can’t read, edit or delete User A’s rows

4User files in private bucketsStorage settingsOnly public assets in public buckets

5JWT checks on user-facing functions`supabase/config.toml`Every `verify_jwt = false` is a deliberate public endpoint

6Limits on paid actionsFunctions plus provider dashboardsPer-user limits and a monthly spending cap on each provider

When to fix it yourself and when to bring someone in:

- **Checks 1, 4 and 6 are self-serve.** Rotating a key, flipping a bucket to private and setting a spending cap don’t need SQL.
- **Checks 2 and 3 need someone who reads SQL** if the advisor flags anything or the two-account test fails. Rewriting policies by prompting the AI that wrote them tends to loop.
- **Check 5 needs a developer** when a function needs its own authorization logic.
- **Failing three or more checks** usually means the app was never designed with access control in mind, and patching one setting at a time won’t hold. That’s the pattern behind the [five production failure modes in Lovable and Bolt MVPs](https://zeroic.in/blog/vibe-coded-mvp-production).

## Sam’s List, VoiceDrop and 100+ audits: what we check first

Zeroic’s [security and performance audits](https://zeroic.in/audits) cover more than 100 applications, for clients including Sam’s List, VoiceDrop and AppSheet Training, and they specialize in Bubble and Supabase, where abstraction layers hide what scanners miss. On a Lovable app we start with the six checks above, then go further than a checklist can: we read the code, test auth and data access by hand with signed-in and signed-out users, and trace every path a key or a row could take out of the server.

Every finding comes back verified, ranked by severity, and with repro steps and a fix, within 1-2 weeks. When the fixes go deeper than settings, such as auth rebuilt, calls moved behind server functions and tests added so the next prompt can’t reopen a hole, that work runs as a [Code Rescue engagement](https://zeroic.in/services/code-rescue): a 3-day review, then 2-4 weeks, with the screens your users know left as they are.

## Frequently asked questions

**Is Lovable secure enough for a production app?**

Lovable can produce a secure app, but it doesn't guarantee one. Its own security docs say the built-in scans cannot guarantee complete security and that you are responsible for meeting your app's security requirements. The platform gives you the tools; the settings in your Supabase project decide whether user data is exposed, so check them before launch.

**Is it safe that my Supabase key is visible in the browser?**

Yes, if it's the publishable or legacy anon key and every exposed table has row level security with correct policies. Supabase designs that key to be public, so anyone can read it and reach whatever your policies allow. A secret or service_role key in the browser is never safe, because it bypasses every row level security policy you have.

**Does Lovable's security scan check row level security policies?**

It checks for tables without per-record access control and for rules that let everyone through, and it runs a quick scan on every publish. It does not prove your policies match your app's logic, and only vulnerabilities rated critical become findings. Test access yourself with two signed-in accounts before you trust a clean scan.

**How do I find a leaked API key in a Lovable or Bolt app?**

Open your live site, load the developer tools, and search every loaded JavaScript file for strings like service_role, sb_secret_, sk_live and sk-. Then search your Git history for the same strings. Any variable with the VITE_ prefix is bundled into the browser code at build time, so treat everything with that prefix as public.

**Do Supabase apps have rate limiting by default?**

Only on Supabase Auth endpoints such as sign-up, sign-in, one-time codes and the built-in email sender. The Supabase rate limit docs list no default limits for database queries or Edge Function calls, so a function that calls a paid AI model, sends SMS or sends email needs its own per-user limit and a spending cap at the provider.

## References

1. [Supabase - Understanding API keys](https://supabase.com/docs/guides/getting-started/api-keys)
2. [Supabase - Securing your data](https://supabase.com/docs/guides/database/secure-data)
3. [Supabase - Row Level Security](https://supabase.com/docs/guides/database/postgres/row-level-security)
4. [Supabase - Advisors](https://supabase.com/docs/guides/observability/advisors)
5. [Supabase - Auth rate limits](https://supabase.com/docs/guides/auth/rate-limits)
6. [Supabase - Securing Edge Functions](https://supabase.com/docs/guides/functions/auth)
7. [Supabase - Storage buckets](https://supabase.com/docs/guides/storage/buckets/fundamentals)
8. [Vite - Env variables and modes](https://vite.dev/guide/env-and-mode)
9. [Lovable - Security overview](https://docs.lovable.dev/features/security)
10. [Matt Palmer - Statement on CVE-2025-48757](https://mattpalmer.io/posts/2025/05/statement-on-CVE-2025-48757/)
11. [UpGuard - Systemic data exposure in Supabase apps](https://www.upguard.com/blog/everything-everywhere-systemic-data-exposure-in-supabase-apps)
12. [Escape - How we discovered vulnerabilities in apps built with vibe coding](https://escape.tech/blog/methodology-how-we-discovered-vulnerabilities-apps-built-with-vibe-coding/)
13. [OWASP API Security - API4:2023 Unrestricted Resource Consumption](https://api-security.owasp.org/editions/2023/en/0xa4-unrestricted-resource-consumption)

#lovable#supabase#security#vibe-coding#rls

More from the journal

[ Software engineering

## [Supabase row level security not working: six causes and fixes](https://zeroic.in/blog/supabase-row-level-security-not-working)

Empty arrays, insert errors and rows anyone can read all trace back to six causes. Here's the symptom, the check and the fix for each.

Prashant Abbi Oct 5, 2026 · 9 min read

[ No-code

## [Lovable vs Bolt vs Cursor: which vibe-coded MVP survives to production (2026)](https://zeroic.in/blog/lovable-vs-bolt-vs-cursor)

What breaks first in apps built with Lovable, Bolt and Cursor, what each costs to fix, and how to pick the tool that fits your team.

Khushi Arora Sep 22, 2026 · 7 min read

[ For founders

## [Code Rescue vs a full rewrite: the real math for vibe-coded MVPs](https://zeroic.in/blog/code-rescue-vs-rewrite)

How to tell whether your cracking Lovable or Bolt app needs a targeted fix or a clean rebuild, and what each one costs.

Khushi Arora Sep 25, 2026 · 7 min read

## Hear from Khushi within 24 hours.

**Khushi Arora** Partner @ Zeroic

Launching a Lovable app and not sure what it exposes? A Zeroic security audit tests your Supabase keys, tables, policies, buckets and functions by hand, then ranks every finding with repro steps and a fix. Fixed price, 1-2 weeks.

[Book a security audit](https://zeroic.in/services/ai-audit), or [book a 30-minute call](https://zeroic.in/book)

Pages [Services](https://zeroic.in/services) [Work](https://zeroic.in/work) [Blog](https://zeroic.in/blog) [About](https://zeroic.in/about) [Guide for AI](https://zeroic.in/llms.txt)

Services [Audits](https://zeroic.in/services/ai-audit) [MVP Sprint](https://zeroic.in/services/mvp-development) [Retainer](https://zeroic.in/services/senior-developers) [Code Rescue](https://zeroic.in/services/code-rescue) [Bubble to code](https://zeroic.in/bubble-to-code) [AI development](https://zeroic.in/ai-development-company)

Industries [Marketplaces](https://zeroic.in/marketplace-app-development) [B2B SaaS](https://zeroic.in/saas-mvp-development) [FinTech](https://zeroic.in/fintech-app-development) [Telehealth](https://zeroic.in/telehealth-app-development) [EdTech](https://zeroic.in/edtech-app-development) [All industries →](https://zeroic.in/industries)

Developers [Bubble](https://zeroic.in/hire-bubble-developers) [React](https://zeroic.in/hire-nextjs-developers) [Python](https://zeroic.in/hire-python-developers) [AI & LLMs](https://zeroic.in/hire-ai-developers) [API integrations](https://zeroic.in/api-integration-services) [All developers →](https://zeroic.in/developers)

Contact [Email](mailto:zeroic.in@gmail.com) [WhatsApp](https://wa.me/919873927225) [LinkedIn](https://www.linkedin.com/company/zeroic/) [X (Twitter)](https://x.com/PrashantAbbi) [Book a call](https://zeroic.in/book)

© 2026 Zeroic [Privacy](https://zeroic.in/privacy) [Terms](https://zeroic.in/terms)

Built in India · Shipping globally

SINCE