What are the most common security issues in Lovable apps?

In order of frequency and severity: (1) Supabase RLS disabled on tables — anyone with your anon key can read all rows. (2) Missing authentication on API routes. (3) Verbose error messages leaking stack traces. (4) Missing security headers (CSP, HSTS). (5) Exposed API keys in client-side code via NEXT_PUBLIC_ prefix.

How do I scan my Lovable app for security issues?

First, enter your app's URL on vibecheck.it.com for a free live scan of headers, TLS, and CORS. Then enable GitHub Sync in Lovable settings, connect the repo to vibecheck, and run a full code scan. The code scan checks for secrets, RLS gaps, unauthenticated routes, and 40 more issues.

Does Lovable store my data or API keys?

Lovable stores the prompts and generated code in your project. Your Supabase API keys are typically in environment variables in the Lovable project settings — not committed to source code. However, if you hardcode a key in a prompt or component, it can end up in the code. Check with Lovable's own security documentation for their current data practices.

Should I enable RLS in Supabase before or after building features?

Before going live, always. Enable RLS and write policies as you build each feature — it is far easier to write correct policies alongside the feature than to retrofit them later. Lovable can often generate the correct RLS policies if you describe the access rules in your prompt.

2 CRITICAL2 HIGH2 MEDIUM

Lovable app security: what to check before going live

Q: Is Lovable secure by default?

Lovable generates functional code quickly, but security is not its primary focus. It commonly generates apps that use Supabase without enabling Row Level Security, and may expose API keys or create API routes without authentication checks. These are not bugs in Lovable — they are gaps developers need to close before going live.

Lovable ships features fast — but security defaults are loose. The six issues below appear repeatedly in Lovable-generated apps and can expose your users' data before you realise the gap exists. Here's how to find and fix each one.

ALSO APPLIES TO

Apps built with Bolt, v0, Cursor, Windsurf, Replit, or any AI coding tool. The same patterns appear across all vibe-coded apps because the AI models optimise for functionality, not security.

6 security checks for Lovable apps

These are the most common vulnerabilities found in Lovable-generated Next.js + Supabase apps, ranked by severity.

CRITICAL

Supabase RLS disabled

Lovable generates Supabase-backed apps with direct anon-key access from the client. Without Row Level Security, any visitor with your public anon key can query, update, or delete every row in your database. Lovable often skips RLS policies to keep generated code simpler.

FIX

Enable RLS on every table in Supabase → Table Editor. Then add policies for SELECT, INSERT, UPDATE, DELETE based on auth.uid().

full guide →

CRITICAL

Exposed API keys via NEXT_PUBLIC_

AI coding tools (including Lovable) sometimes prefix secret environment variables with NEXT_PUBLIC_ for convenience. This embeds the literal key value into your JavaScript bundle — visible to any visitor in DevTools or via a simple curl request.

FIX

Remove the NEXT_PUBLIC_ prefix and move any calls using that key into a Server Action or API route.

full guide →

HIGH

Unauthenticated API routes

Lovable-generated API routes often omit authentication checks, relying on Supabase RLS as the only guard. If RLS is misconfigured or the route uses a service_role key, every route becomes a backdoor. Routes like /api/users, /api/orders, or /api/admin are common targets.

FIX

Add an auth check at the top of every route handler: verify the session with getServerSession (NextAuth), supabase.auth.getUser(), or your auth provider before processing the request.

guide coming soon

HIGH

Verbose error responses

Lovable-generated catch blocks often include catch(err) { return Response.json({ error: err.message }) }. Sending raw error messages to clients reveals your database schema, file paths, query structure, and library versions to attackers.

FIX

Log the full error server-side (console.error), return a generic message to the client (e.g. "Something went wrong"), and never include err.message, err.stack, or err.code in the response body.

guide coming soon

MEDIUM

Missing security headers

Lovable apps deployed to Vercel ship without a Content-Security-Policy, Strict-Transport-Security, or X-Frame-Options header by default. These headers prevent XSS, clickjacking, and protocol downgrade attacks.

FIX

Add a next.config.js headers() function that sets CSP, HSTS, X-Frame-Options: DENY, X-Content-Type-Options: nosniff, and Referrer-Policy.

guide coming soon

MEDIUM

Missing cookie security flags

Session and auth cookies without HttpOnly, Secure, and SameSite=Lax flags are vulnerable to XSS theft and CSRF. Lovable-generated auth flows using client-side storage (localStorage) are especially at risk.

FIX

Use an HttpOnly cookie for session storage. If using Supabase Auth, configure it to use cookies (ssr package) rather than localStorage.

guide coming soon

How to audit your Lovable app

A 15-minute manual review you can do right now:

01
Check RLS in the Supabase dashboard
Supabase → Table Editor. Look for the shield icon on each table. Grey = RLS off. Click the table → Policies → Enable RLS. If there are no policies after enabling, all rows will be blocked — add at least a SELECT policy.
02
Enable GitHub Sync and pull the code
In Lovable: Settings → GitHub Sync → Connect. This gives you a GitHub repo you can clone and scan properly. Without this, you're auditing blind.
03
Grep for NEXT_PUBLIC_ secrets
After cloning: grep -r "NEXT_PUBLIC_" . --include="*.ts" --include="*.tsx" --include=".env*" — look for anything that doesn't belong in the browser (AI API keys, service keys, signing secrets).
04
Test each API route without auth
With the dev server running: curl http://localhost:3000/api/users — check if you get data back without an Authorization header. Repeat for every route under /api.
05
Run a live header check
Enter your deployed URL on vibecheck.it.com. Takes 30 seconds. Shows missing CSP, HSTS, X-Frame-Options, cookie flags, TLS issues, and CORS misconfigs.

Scan your repo automatically

vibecheck runs four scanners against your Lovable-synced GitHub repo in about 60 seconds:

Gitleaks

Finds secrets in code and git history — API keys, tokens, connection strings.

Semgrep

Flags SQL injection, SSRF, XSS, path traversal, and injection patterns.

njsscan

Node.js-specific checks: eval(), crypto misuse, insecure dependencies.

43 custom checks

Supabase RLS, unauth routes, NEXT_PUBLIC_ secrets, and 40 more Lovable-specific patterns.

ℹ

Free for 2 repos. No credit card. Findings are triaged by Claude and explained in plain English — not raw scanner output.

Scan your Lovable app — free

Connect the GitHub repo Lovable synced. vibecheck runs in ~60 seconds and shows you exactly what to fix, in order of severity.

scan my Lovable app →check headers first (no signup)

FAQ

Is Lovable secure by default?

Lovable generates functional code fast, but it prioritises shipping features over security hardening. RLS, auth checks, and security headers are gaps you need to close yourself before going live with real user data.

Does Lovable use Supabase for every app?

Not always — but most Lovable apps use Supabase as the backend. The RLS and API key issues in this guide apply specifically to Supabase-backed Lovable apps.

Can Lovable fix these issues if I describe them in a prompt?

Yes, for most of them. Lovable can write correct RLS policies, add auth checks to routes, and move secrets server-side if you describe exactly what you want. Use the fixes in each section above as the basis for your prompt.

My app is on Vercel. Does that affect the security issues here?

Vercel manages TLS and provides some infrastructure security, but it does not add RLS to your Supabase tables, authenticate your API routes, or prevent secrets from ending up in your bundle. The application-level issues still apply.

What about Bolt and v0 apps — are the same issues present?

Yes. Bolt (by StackBlitz) and v0 (by Vercel) generate similar Next.js + Supabase patterns and have the same RLS, unauth routes, and secret exposure risks. This entire guide applies to apps built with either tool.