Lovable Security: Risks, Incidents & Best Practices

Two different security stories, and why they get confused

Search results and forum posts about "Lovable security" usually blend two separate events into one scary headline. The first is CVE-2025-48757 (CVSS 8.26), disclosed May 2025 by researcher Matt Palmer: scanning 1,645 apps from Lovable's public showcase, he found 170 apps (about 10%), 303 endpoints, where Supabase tables were readable or writable using just the public anon key because Row Level Security had never been enabled on those tables - exposing emails, addresses, and in some cases API keys. This is a misconfiguration in apps that people built, amplified by the fact that Lovable's default output didn't always force RLS on. It is not evidence that Lovable's own infrastructure was breached. The second, separate event happened almost a year later. On April 20, 2026, researcher @weezerOSINT disclosed a genuine platform-level bug: a backend regression (a BOLA-type access control flaw) active from February 3 to April 20, 2026, meant anyone with a link to a public Lovable project could read that project's chat history and source code - not private projects, not Lovable Cloud data. Reports had come in through HackerOne since February 22. Lovable's official response, published April 22, says the issue was fixed within two hours of full understanding, all public projects (except official templates) were converted to private, and affected owners were notified. Lovable explicitly calls this a 'security incident,' not a 'breach,' and states that private projects and Lovable Cloud were never impacted - a framing that drew criticism from press coverage at the time for downplaying the disclosure timeline. Both stories are real. Neither should be ignored. But they point to different fixes: the first is on you, the builder, to close with RLS; the second was on Lovable, and by their account, already closed.

• CVE-2025-48757 (May 2025): missing RLS in user-built apps exposed data via the public anon key - a build-time configuration gap, not a platform breach
• The April 2026 platform incident: a backend regression let public project chat/code be read by anyone with a link, fixed within hours per Lovable's account
• Broader vibe-coding research suggests a meaningful share of AI-generated apps ship with security gaps across the industry, not unique to Lovable
• Lovable's own certifications (SOC 2, ISO 27001) cover the company's infrastructure and processes - they don't automatically cover security mistakes in the apps you build with it

Error messages you might see

Before you start

• A Lovable project connected to Lovable Cloud or an external Supabase database
• Access to the Cloud tab (Database section) to review table-level security settings
• A clear list of which data in your app is sensitive (personal info, payments, health data) versus non-sensitive
• A Pro, Business, or Enterprise plan if you want access to Deep Scan and enterprise security integrations

How to fix it

-- Table created without RLS - readable/writable by anyone with the anon key
CREATE TABLE public.orders (
  id uuid PRIMARY KEY DEFAULT gen_random_uuid(),
  user_id uuid REFERENCES auth.users(id),
  total numeric,
  created_at timestamptz DEFAULT now()
);

ALTER TABLE public.orders ENABLE ROW LEVEL SECURITY;
CREATE POLICY "Users can view their own orders"
  ON public.orders FOR SELECT
  USING (auth.uid() = user_id);
CREATE POLICY "Users can insert their own orders"
  ON public.orders FOR INSERT
  WITH CHECK (auth.uid() = user_id);

Complete code example

1-- Example: locking down a table so users can only see and modify their own rows.
2-- Run this pattern for every table that stores user-specific data.
3
4ALTER TABLE public.profiles ENABLE ROW LEVEL SECURITY;
5
6-- Users can read their own profile
7CREATE POLICY "select_own_profile"
8  ON public.profiles FOR SELECT
9  USING (auth.uid() = id);
10
11-- Users can update their own profile
12CREATE POLICY "update_own_profile"
13  ON public.profiles FOR UPDATE
14  USING (auth.uid() = id)
15  WITH CHECK (auth.uid() = id);
16
17-- No public INSERT/DELETE policy defined here on purpose -
18-- account creation should go through your auth flow, not a direct table insert.
19
20-- Verify: query this table using the anon key (no auth session) and confirm
21-- zero rows are returned. Then verify a logged-in user only sees their own row.

Best practices to prevent this

• Enable Row Level Security on every table before adding any real user data - never postpone this
• Run Basic and Deep security scans before every launch and after any schema or auth change
• Distinguish user-app misconfigurations (your responsibility) from Lovable platform incidents (Lovable's responsibility) when assessing actual risk
• Never paste raw API keys into chat prompts or code - use Secrets, which Lovable also auto-detects and protects
• Review the trust center (trust.lovable.dev) for current certification status when responding to vendor security questionnaires
• Keep projects private unless you have a specific reason to make them public, especially anything with real user data
• Get a manual security review before launching anything handling sensitive, regulated, or financial data

Still stuck?

Copy one of these prompts to get a personalized, step-by-step explanation.

Related error patterns