DEV Community

Not Elon
Not Elon

Posted on

I Scanned 30 Lovable Apps This Month. Here Are the 5 Security Issues I Found in Almost Every One

#lovable #security #vibecoding #webdev

I run security scans on vibe-coded apps. This month I looked at 30 apps built with Lovable, and the same five issues appeared in nearly every one.

These are not theoretical risks. They are things any user with browser DevTools could exploit in under five minutes.

1. Supabase RLS policies that check role instead of ownership

This was in roughly 80% of apps that use Supabase.

The AI generates a Row Level Security policy like this:

CREATE POLICY "Users can view data"
ON public.user_data
FOR SELECT
USING (auth.role() = 'authenticated');
Enter fullscreen mode Exit fullscreen mode

This means any logged-in user can read every row in the table. Not just their own. Every user's data.

The fix is one function call: auth.uid() = user_id instead of auth.role() = 'authenticated'.

I wrote a full guide on checking and fixing this.

2. Supabase anon key + service role key in the JavaScript bundle

Every Lovable app that uses Supabase ships the anon key in the client bundle. That part is expected and documented by Supabase.

The problem: about 1 in 5 apps I scanned also had the service role key in the client bundle. The service role key bypasses all RLS policies. If someone extracts it from your JavaScript (which takes about 30 seconds with DevTools), they have full read/write access to every table.

How to check: Open your deployed app. View page source. Search for eyJ (the start of a base64-encoded JWT). You should find exactly one key (the anon key). If you find two, the second is probably your service role key.

The fix: Move any server-side logic that uses the service role key into a Supabase Edge Function or server-side API route. Never import the service role key in client code.

3. No email verification required

Lovable apps typically set up Supabase Auth with email + password. The AI generates the signup flow, the login flow, and the protected routes.

What it does not generate: email verification.

This means anyone can sign up with any email address (including addresses they do not own) and immediately access the app. Combined with the RLS issue from #1, they can also read every other user's data.

How to check: Go to your Supabase dashboard > Authentication > Settings > Email. Look for "Enable email confirmations." If it is off, anyone can sign up with a fake email.

The fix: Enable email confirmations in Supabase. Then update your app's auth flow to handle the "check your email" state between signup and confirmation.

4. API keys for third-party services in environment variables that get bundled

This goes beyond Supabase. If your Lovable app uses OpenAI, Stripe, SendGrid, or any other service with an API key, check where that key lives.

Lovable apps built with Vite expose any environment variable that starts with VITE_ to the client bundle. If your OpenAI key is stored as VITE_OPENAI_API_KEY, it ships to every user's browser.

How to check: Open DevTools > Sources > find your compiled JS files > search for your key prefix or the string sk- (OpenAI) or SG. (SendGrid).

The fix: Any key that costs money when called (OpenAI, Stripe secret key, SendGrid) must live on the server side only. Create a Supabase Edge Function or backend API that proxies the request.

5. No rate limiting on authentication endpoints

None of the 30 apps I scanned had rate limiting on their auth endpoints. This means an attacker can attempt unlimited password guesses, send unlimited password reset emails, or create unlimited accounts.

Supabase has built-in rate limiting for auth, but the defaults are generous and the AI never tightens them.

How to check: Open Supabase dashboard > Authentication > Rate Limits. Look at the current settings.

The fix: Set rate limits that make sense for your app. For most apps: 5 signups per hour per IP, 10 login attempts per hour per IP, 3 password reset emails per hour per email.

Why these keep appearing

The pattern is consistent: Lovable (and other AI tools) optimize for "the feature works" not "the feature is secure." Every one of these apps worked correctly. Users could sign up, log in, and use every feature. The security gaps were invisible during normal use.

The AI does not add security controls unless you specifically prompt it to. And most builders do not know what to prompt for because they are not security experts. That is the whole point of vibe coding.

What to do about it

If you have a Lovable app with real users:

  1. Run the Supabase RLS check from issue #1 right now. It takes 2 minutes.
  2. Search your client bundle for eyJ and count the JWT tokens. If there are more than one, you have a problem.
  3. Search for sk- and SG. in your bundle.
  4. Check your auth email verification setting.
  5. Review your rate limits.

We built free scanning tools at notelon.ai that automate checks 2-4. No signup required.

If you want a human review covering all five issues plus business logic, auth flows, and API design, our $99 security audit covers 50+ checks with a PDF report and fix instructions.

Part of the Vibe Coding Security series. Updated weekly with new findings.

Top comments (0)