DEV Community: Tomer goldstein

Is Lovable Actually Secure? I Checked the Supabase RLS on 50 Apps

Tomer goldstein — Tue, 14 Apr 2026 17:07:29 +0000

So I've been on this thing where I scan AI-generated apps for security holes. Did it with Cursor first - 67% had critical vulns. That post blew up a bit so I figured — let's do Lovable next.

If you don't know Lovable: you describe what you want, it builds you a full React + Supabase app. Auth, database, the whole thing. It's honestly impressive for prototyping.

For production though? Yeah... about that.

I scanned 50 Lovable repos. Real apps that people actually deployed. Not toy projects.

The same 5 vulnerabilities showed up in almost every single one.

1. No Row Level Security — 89% of apps

This one's rough.

Lovable creates your Supabase tables but just... doesn't turn on RLS. No policies. Nothing.

What that means: any user who's logged into your app can read, edit, or delete every other user's data. They don't even need to hack anything — just call the Supabase API directly and skip your frontend.

-- What Lovable generates
CREATE TABLE public.projects (
  id UUID DEFAULT gen_random_uuid() PRIMARY KEY,
  user_id UUID REFERENCES auth.users(id),
  name TEXT NOT NULL,
  data JSONB
);
-- That's it. No RLS. Your database is basically public.

The fix takes 2 minutes per table:

ALTER TABLE public.projects ENABLE ROW LEVEL SECURITY;

CREATE POLICY "Users see own projects"
  ON public.projects FOR SELECT
  USING (auth.uid() = user_id);

CREATE POLICY "Users insert own projects"
  ON public.projects FOR INSERT
  WITH CHECK (auth.uid() = user_id);

89% of apps didn't have this. Eighty-nine percent.

2. Service Role Key in Client Code — 34%

Lovable sometimes initializes the Supabase client with the service role key instead of the anon key. Quick explainer if you're not deep in Supabase: the service role key bypasses ALL security policies. It's the god-mode key.

When it's in your client-side code, it ships in your JavaScript bundle. Anyone who opens DevTools has it.

// nah fam
const supabase = createClient(
  process.env.NEXT_PUBLIC_SUPABASE_URL!,
  process.env.NEXT_PUBLIC_SUPABASE_SERVICE_ROLE_KEY! // bypasses ALL RLS
);

Fix: use the anon key on the client. Service role key stays server-side only. Always.

3. Querying auth.users Directly — 28%

Instead of creating a profiles table, Lovable sometimes queries auth.users directly. That table has hashed passwords and email confirmation tokens in it.

Just... create a profiles table. Set up a trigger to sync it. This is Supabase 101.

4. Secrets in VITE_ / NEXT_PUBLIC_ Vars — 22%

Lovable puts sensitive stuff behind VITE_ or NEXT_PUBLIC_ prefixes, which means they get bundled into the browser JavaScript.

Database connection strings. Webhook secrets. In the browser. Where anyone can read them.

Fix: if it's sensitive, don't prefix it. Access it from server-side code only.

5. Zero Input Validation — 18%

Form data goes straight to Supabase. No Zod, no type checking, nothing. Whatever someone sends, your database accepts.

The Pattern

Lovable optimizes for "it works." And it does work — fast. But "works" and "secure" are two very different things. The AI doesn't think about what happens when someone goes around your UI and talks to your database directly.

Every one of these fixes takes less than 30 minutes if you know what to look for.

Check Yours

If you shipped something with Lovable:

Supabase dashboard → Table Editor → check if RLS is on (it's probably not)
Search your code for SERVICE_ROLE — if it's in any client file, move it
Search for VITE_ and NEXT_PUBLIC_ — are any of those actually secrets?

Or just paste your GitHub URL into ship-safe.co — free scan, 2 minutes, checks all of this.

Building ShipSafe — scans AI-generated apps for the stuff the AI forgot. Free, no card. If you vibe-code, you probably need this.

Your Vibe Coding Security Scanner Is Missing the Worst Bugs. Here's Why.

Tomer goldstein — Thu, 02 Apr 2026 12:55:08 +0000

there are like 8+ security scanners for vibe-coded apps now. a year ago there were zero. we went from "just ship it and pray" to having actual tools. love to see it.

but here's the thing nobody's talking about: these tools don't all scan the same stuff. and the difference between them decides whether you catch the bugs that actually get you hacked or just the surface-level ones.

I built one of these scanners (ShipSafe) and I've been testing the others too. the split is simple: does it scan your deployed URL or your actual source code? that one question changes everything.

the two flavors

URL scanners hit your live site from the outside. they catch missing headers, exposed endpoints, leaked keys in your JS bundle, SSL issues. real stuff. useful.

repo scanners read your actual code. they look at auth logic, database queries, how secrets are handled on the server. different game entirely.

most people assume these overlap more than they do. they don't. like, at all.

three bugs URL scanners literally cannot find

these are from real AI-generated codebases. I keep running into them.

the backwards auth

export function middleware(req) {
  const token = req.cookies.get("session");
  if (token) {
    return NextResponse.redirect("/login");
  }
  return NextResponse.next();
}

missing !. logged-in users get kicked, anonymous users get in. found this in 31% of Cursor apps I scanned.

why a URL scanner is blind to it: you hit the page without auth, get a 200 back. scanner says "looks good." it has zero way of knowing the logic is flipped — that's a source code problem. the app looks normal from the outside. it's just completely open.

IDOR with no ownership check

export async function GET(req, { params }) {
  const invoice = await db.invoice.findUnique({
    where: { id: params.id },
  });
  return Response.json(invoice);
}

change the ID, get someone else's data. 43% of apps had this.

URL scanner hits it, gets a 200 with JSON, says "valid response." it can't tell the difference between your invoice and someone else's invoice — both look the same from the outside. you have to read the Prisma query to see there's no userId filter. that's in the source.

admin API with no backend check

// React hides the button. cool I guess.
if (user.role !== "admin") return null;

// API deletes users. no check. anyone can call this.
export async function DELETE(req, { params }) {
  await db.user.delete({ where: { id: params.id } });
  return Response.json({ success: true });
}

scanner visits the page, doesn't see admin buttons (they're conditionally rendered), reports clean. meanwhile curl -X DELETE /api/users/123 works for literally anyone. the endpoint isn't even linked in the DOM so the scanner never discovers it.

being real tho — repo scanners miss stuff too

gotta keep it honest:

runtime config - your code is fine but someone set the wrong env var on Vercel. repo scanner can't see that
infra issues — permissive CORS at the CDN level, open ports on your VPS. not in the code
database config — Supabase RLS policies live in Postgres, not your repo
deploy drift — you fixed it locally but forgot to push. the deployed version is still cooked

so yeah neither approach is complete on its own.

the actual move

run both. I'm not just saying that bc I built a repo scanner — I use URL tools on my own stuff too.

layer	tool	catches
source code	ShipSafe, ChakraView, Aikido	auth logic, IDOR, secrets in server code
live site	VibeCheck, amihackable.dev	exposed endpoints, headers, runtime config
dependencies	`npm audit`, Snyk	known CVEs in packages
database	Supabase dashboard	RLS policy issues

the thing is - the vulns that actually lead to data breaches in AI code are almost always logic bugs. backwards conditions, missing ownership checks, unprotected endpoints. that stuff lives in the source. it's invisible from the outside. a URL scanner literally cannot catch a missing ! in your middleware. it just can't.

quick gut check for your current setup: can your scanner find a missing ! in middleware? can it tell that a Prisma query doesn't filter by userId?

if the answer is no, you've got a blind spot. and it's the layer where the critical stuff lives.

ShipSafe scans your GitHub repo for auth bugs, IDOR, hardcoded secrets, and OWASP Top 10 vulns. free plan, no credit card.

Is Cursor Safe? I Scanned 100 Apps. 67% Had Critical Vulns.

Tomer goldstein — Tue, 31 Mar 2026 09:49:07 +0000

so I've been building ShipSafe — security scanner for AI-generated code — and a few weeks ago I got curious. like, actually curious. not "I wonder if AI code has bugs" curious, more like "how bad is it really and am I just being paranoid" curious.

I grabbed 100 Cursor-built repos off GitHub. not tutorials, not demo apps. real production stuff — SaaS tools, internal dashboards, a couple e-commerce stores, bunch of API backends. found them by searching for .cursorrules files and Cursor-style commit patterns.

then I scanned all of them with ShipSafe.

67%. sixty-seven percent had at least one critical vulnerability. the worst app had 14 separate issues. fourteen. average was 3.2 per app.

ngl I expected some problems but not... that.

	% of apps
had a critical vuln	67%
IDOR	43%
inverted auth	31%
frontend-only admin checks	28%
hardcoded secrets	22%

this tracks with Stanford research that found ~45% of AI-assisted code has vulns. our numbers are worse, probably bc we only looked at shipped production apps vs their lab setup.

anyway. let me show you what I kept finding.

the IDOR thing (43%)

this was by far the most common. and it's so dumb that it's almost funny? Cursor generates an API route, takes an ID from the URL, fetches from the database, returns it. no check on who's asking.

// /api/invoices/[id]
export async function GET(req, { params }) {
  const invoice = await db.invoice.findUnique({
    where: { id: params.id },
  });
  return Response.json(invoice);
}

change /api/invoices/42 to /api/invoices/43. congrats you're reading someone else's invoice now. their name, the amount, payment status, all of it. OWASP literally lists this as vulnerability #1.

the fix btw:

where: {
  id: params.id,
  userId: session.user.id, // this. this is the whole fix.
},

one line. Cursor never adds it. and I get why — the AI is optimizing for "does it work" not "who's allowed to see this." but still. 43%.

the backwards auth thing was the wildest tho

okay 31% of these apps had their auth middleware inverted. and I know that sounds fake but look at this:

export function middleware(req) {
  const token = req.cookies.get("session");

  if (token) {
    return NextResponse.redirect("/login");
  }
  return NextResponse.next();
}

if (token) → kick to login. so logged-in users get redirected away. and if you DON'T have a token? NextResponse.next() — come right in. every protected route, wide open to anyone without a session.

one missing !. that's it. if (!token) vs if (token).

and here's what makes it so nasty — you will never find this by testing your own app. you're logged in while you test. the redirect fires on you and maybe you think "huh that's weird" and hack around it or don't even notice bc your session is cached. meanwhile an attacker shows up with zero cookies and gets full access to everything. no cap the first time I saw this in a real production app I just stared at it for like 30 seconds.

frontend admin checks that do nothing

28% of apps had this pattern where Cursor puts the role check in React but not on the server. and I gotta admit this one annoys me the most bc it's so close to being right.

// this part is fine honestly
if (user.role !== "admin") return <Redirect to="/" />;

// this part is NOT fine
export async function DELETE(req, { params }) {
  await db.user.delete({ where: { id: params.id } });
  return Response.json({ success: true });
}

the admin panel is hidden in the UI. great. but curl -X DELETE /api/users/123 works for literally anyone. the API doesn't check anything. Cursor generated the visual gate and forgot the actual gate.

I started telling people: frontend is what you see, backend is what you can do. Cursor gets the see part right every time. the do part? apparently optional.

hardcoded secrets + a personal L

22% had keys in the source. and tbh this is the one I'm least judgmental about bc I almost did this myself early on.

you're setting up Stripe or whatever. you paste your API key into Cursor's chat for context. Cursor writes the integration and puts the key right there in the file:

export const stripe = new Stripe("sk_live_51N8x...");

you commit, push, and now that key is in your git history permanently. deleting the file doesn't help — git log remembers. GitGuardian says 12.8 million secrets were exposed on GitHub last year and I bet a huge chunk started exactly like this.

I almost shipped a Supabase service role key this way. caught it in a scan literally the day before pushing to prod. that's actually one of the reasons I started building ShipSafe — I needed it for myself first.

why tho

okay so why does Cursor keep doing this? I've thought about it a lot and I think there's two things going on.

first — LLMs learn from GitHub. and most code on GitHub is focused on making things work. security is an afterthought in like 90% of open source repos. so the model generates happy-path code. auth checks, ownership verification, input validation — that stuff doesn't make the app function, it prevents exploitation. the model literally doesn't prioritize it unless you specifically ask.

second thing — and this is the one that's harder to fix — Cursor thinks about one file at a time. it'll generate a totally reasonable API route without knowing that your middleware in some other directory is supposed to handle auth. or that it doesn't. the context window sees the file you're working on, not the security architecture of your whole app.

tbh the second one bugs me more than the first bc you can kinda solve the first one with good .cursorrules but the file-at-a-time thing is structural.

what actually changed my workflow

I'm not gonna stop using Cursor over this. the speed boost is too real. but I did change a few things and it's made a huge difference.

biggest one — I added security-specific rules to my .cursorrules file. things like "always add userId to database where clauses" and "never hardcode secrets, always use process.env." sounds simple but it legit changed the output quality. night and day.

the other thing is I just manually review auth-related code now. everything else, Cursor handles and I trust it. but middleware files, API route guards, anything with role checks — I actually read those line by line. takes like 5 minutes per PR and it's caught issues multiple times.

and obviously I run ShipSafe before deploying. that's the whole reason I built it lol. paste the GitHub URL, get a report, fix the flagged stuff, ship. couple minutes.

oh and I stopped pasting real API keys into Cursor chat. use fakes, swap in real ones through env vars. learned that one the hard way with the Supabase key thing I mentioned.

Cursor makes you stupid fast. I'm not going back to writing everything manually. but "fast" and "secure" aren't the same thing and 67% of production apps having critical vulns is a pretty loud signal.

just add a scan to your deploy flow. like two minutes. saves you the 2am incident response call.

full data + methodology: ship-safe.co/blog/is-cursor-code-secure

free scan: ship-safe.co

I scanned 100 AI-generated apps for security vulnerabilities. Here's what I found.

Tomer goldstein — Tue, 24 Mar 2026 19:39:09 +0000

I've been building a security scanner for the past few months, specifically designed for apps built with AI coding tools like Cursor, Lovable, Bolt.new, and v0.

To validate whether the tool was actually useful, I scanned 100 real GitHub repos - all built primarily with AI assistance. The results were worse than I expected.

The numbers

67 out of 100 repos had at least one critical vulnerability
45% had hardcoded secrets (API keys, JWT secrets, database URLs in source code)
38% had missing authentication on sensitive API routes
31% had SQL injection or XSS vulnerabilities
89% of Lovable apps were missing Supabase Row Level Security policies

This isn't a theoretical exercise. These are real apps, some already deployed with real users.

The most common vulnerabilities by AI tool

Cursor

The biggest issue with Cursor-generated code is IDOR (Insecure Direct Object References). Cursor loves to use sequential IDs and often skips ownership checks:


javascript
// Cursor generates this — anyone can access any user's data
app.get('/api/users/:id', async (req, res) => {
  const user = await db.users.findById(req.params.id);
  res.json(user);
});

It should verify the requesting user owns that resource. 43% of Cursor repos had this pattern.

Lovable
Lovable builds beautiful Supabase apps, but it almost never enables Row Level Security. This means any authenticated user can read/write any row in any table:

-- This is what Lovable usually generates: nothing
-- What it should generate:
ALTER TABLE todos ENABLE ROW LEVEL SECURITY;

CREATE POLICY "Users can only see their own todos"
ON todos FOR SELECT
USING (auth.uid() = user_id);

89% of Lovable repos were missing RLS on at least one table with user data.

Bolt.new
Bolt.new's biggest weakness is unauthenticated API routes. It generates Express/Next.js API handlers that accept POST, PUT, and DELETE requests with zero auth checks:

// No auth check — anyone on the internet can delete data
export async function DELETE(req) {
  const { id } = await req.json();
  await db.delete(items).where(eq(items.id, id));
  return Response.json({ success: true });
}

52% of Bolt.new repos had at least one unprotected mutating endpoint.

Why AI tools create these vulnerabilities
It's not that the AI models are bad at coding. The problem is more specific:

No threat model. AI generates code that satisfies the functional requirement ("build a todo app") but doesn't consider adversarial use ("what if someone guesses another user's ID?")

Training data bias. Most code on GitHub — which these models trained on — is tutorial code, demos, and prototypes. Production security patterns are underrepresented.

Context window limits. Security often requires understanding the full system (auth flow + database policies + API routes). AI generates one file at a time and loses cross-file context.

No feedback loop. When AI writes a working but insecure endpoint, nobody tells the model it was wrong. The code works, tests pass, users can log in — the vulnerability is invisible until exploited.

Stanford and UIUC researchers found that developers using AI assistants produced significantly less secure code than those coding manually, yet were more confident their code was secure. That confidence gap is dangerous.

What you can do about it
1. Never trust AI with auth logic
Always manually review authentication and authorization code. This is the highest-risk area.

2. Check for hardcoded secrets
Run a quick grep:

grep -rn "sk_live\|sk_test\|api_key\|password\|secret" --include="*.ts" --include="*.js" .

3. Enable RLS if using Supabase
Every table with user data needs Row Level Security. No exceptions.

4. Add auth middleware to all mutating routes
Every POST, PUT, DELETE, and PATCH endpoint needs authentication. Create a middleware function and apply it consistently.

5. Run an automated scanner
This is why I built ShipSafe. Paste a GitHub URL, get a report in 2 minutes with plain-English explanations and specific fixes. Free scan covers 30+ checks, paid plans add AI-powered deep analysis.

The bottom line
AI coding tools are incredible for speed. I use Cursor every day. But they have a blind spot for security, and that blind spot is predictable and fixable.

The vulnerabilities AI creates aren't exotic zero-days. They're the same OWASP Top 10 issues that have existed for 20 years — just generated faster and at scale.

Scan your code. Fix what matters. Ship with confidence.

If you're building with AI tools, I'd love to hear what security issues you've encountered. Drop a comment — I'm curious whether your experience matches what we found.