Lovable app security: the flaws to check before you launch
Lovable generates a full React app in a few prompts, wired to Supabase for the database and authentication. That speed is exactly the risk: the interface works, but nothing guarantees your users’ data is protected on the server side.
In 2025, researchers showed that more than 170 apps built with Lovable let anyone read or modify their data, because of missing or wrong Row Level Security rules (CVE-2025-48757). The flaw wasn’t in Lovable itself, but in how the generated databases were configured.
Ten free analyses every month, no card needed. First report in minutes.
Analyse my app for freeThe most common flaws
Supabase tables without Row Level Security
Supabase’s “anon” key is public: it ships in your site’s code. Without RLS, that key alone is enough to read the whole users, orders or messages table.
Overly permissive policies
A policy written as “USING (true)” to make a screen work grants access to everyone. It is a typical fix an AI suggests when a query fails.
service_role key in the browser
The service_role key bypasses every rule. If it ends up in a VITE_ variable or in client code, your database is wide open.
Checks done only on screen
Hiding an “admin” button doesn’t stop anyone from calling the API directly. Permissions must be enforced in the database or on the server.
What Citadel checks (15 live checks)
Code, dependency and secret analysis against OWASP and CWE. Every flaw comes with a plain explanation and the fix prompt to paste into your assistant.
- service_role key used in client code CWE-798 · A07
- Tables exposed without Row Level Security enabled CWE-284 · A01
- Permissive policies: USING (true) or WITH CHECK (true) CWE-284 · A01
- Secrets in the code and config files (100+ key types) CWE-798 · A07
- npm and Composer dependencies with published CVEs or GHSA advisories A06 · CVSS
- Passwords hashed with MD5, SHA-1 or unsalted CWE-916 · A02
- http:// redirects to https:// CWE-319 · A02
- HSTS present with a sufficient duration CWE-319 · A05
- CSP present, without unsafe-inline or unsafe-eval CWE-693 · A05
- Protection against embedding in another page (clickjacking) CWE-1021 · A05
- Secure, HttpOnly and SameSite cookies CWE-614 · CWE-1004
- CORS open to every site with cookies CWE-942 · A05
- nosniff and Referrer-Policy headers, server version hidden CWE-693 · CWE-200
- Forms sent in clear text, or password passed in the URL CWE-319 · CWE-598
- Forms without an anti-CSRF token, or sent to another domain CWE-352 · CWE-201
Frequently asked questions
How do I check if my Lovable app is secure?
Export the code to GitHub from Lovable, then connect the repository to Citadel or upload an archive. The analysis checks RLS rules, exposed keys and dependencies, and gives you the fixes in priority order.
Is the Supabase anon key visible in my site a problem?
No, that is by design: it is meant to be public. What matters are the RLS rules that limit what it can do. Without them, it opens everything.
Is my code kept?
No. It is analysed in an isolated container with no internet access, then deleted as soon as the analysis ends. Only the results are kept, with secrets masked.
How much does it cost?
The Free plan includes ten analyses a month, no card needed. Paid plans add Citadel AI, analysis on every push and team work.
Other guides
Vibe coding security: the checklist before you put your app online