DEV Community: SystAgProject

I Audited 9 Vibe-Coded Apps in 24 Hours. Here Are the 5 Patterns That Show Up Every Single Time.

SystAgProject — Mon, 20 Apr 2026 00:34:55 +0000

Yesterday I ran VibeScan — my security-audit tool for AI-generated SaaS — against 9 public apps built on Lovable / Bolt / v0 / Cursor. Different verticals: healthcare (patient records), finance (AI script-for-sale platform), productivity (logic/notes tools), crypto (CELO transfers), gym management, blockchain auditing.

Total: 145 findings, 9 critical, 75 high, 61 medium.

Five patterns showed up in basically every single one. Not "I saw them occasionally" — I saw them in 8-9 out of 9. If you're shipping an AI-coded SaaS right now, these are the ones to fix tonight, before anyone signs up.

1. RLS policies with `USING (true)` — "looks secure, isn't"

Hit rate: 8 / 9 codebases.

Every single app I scanned had Supabase RLS enabled on its core tables. That looks fine — RLS is on. Until you read the policies:

CREATE POLICY "authenticated users can read"
  ON public.cases FOR SELECT TO authenticated
  USING (true);

If cases stores per-user data and your app has open signup, this is a fancy way of saying: "anyone who creates a throwaway Gmail account reads every other user's records." I saw this on medical case files, on AI generation history, on gym-member workout logs. On one healthcare app, any signed-in user could read AND modify every patient record + physician note + uploaded file in the database.

Fix:

USING (user_id = auth.uid())

For UPDATE policies, add WITH CHECK (user_id = auth.uid()) too, or users can flip the user_id column during their update and steal other people's rows.

I wrote a full tutorial on getting RLS right earlier today — it's the single highest-impact thing you can fix this week.

2. Unauthenticated edge functions — "verify_jwt = false"

Hit rate: 9 / 9 codebases.

Every single app had at least one edge function with verify_jwt = false in supabase/config.toml. Sometimes a half-dozen. Most of them were AI endpoints (calls to OpenAI, Gemini, Claude) or payment webhooks.

[functions.payment-webhook]
verify_jwt = false

Payment webhooks need this — Stripe has to be able to call you without a user JWT. But the fix is then to verify the signature inside the function:

const event = stripe.webhooks.constructEvent(
  body,
  req.headers.get("stripe-signature"),
  Deno.env.get("STRIPE_WEBHOOK_SECRET"),
);

On 7 of the 9 apps, that verification was missing or replaced by a shared secret sent in a custom header (which is worse — the secret travels over the wire on every request and leaks into logs).

On AI endpoints with verify_jwt = false, the function is world-callable. Anyone can hit it in a while(true) loop and drain your OpenAI credits in an hour. On one app the LLM endpoint would happily accept 2MB request bodies. Attacker math: $X credits per request × unlimited requests → bye bye balance.

Fix: turn verify_jwt = true back on for anything that isn't a payment webhook, then verify auth inside the function. For the webhook exceptions, verify the provider signature.

3. No rate limit on AI / generation / contact / signup endpoints

Hit rate: 9 / 9 codebases.

None of the 9 apps had rate limiting in front of their expensive endpoints. Not on AI generation. Not on contact forms. Not on signup. Not on password reset.

This matters in two flavors:

Credit drain: the AI-generation endpoint on one app would gladly take a 50,000-character prompt and call GPT-4 on it. No cap on requests per user, no cap on input size. A single compromised account runs up a $500 bill overnight.
Signup / spam flood: one app had open signup with no captcha and no rate limit. Combined with the USING (true) RLS issue, that means an attacker can spin up 10,000 fake accounts and each one gets read access to all the real users' data.

Fix (Supabase edge functions):

import { Ratelimit } from "@upstash/ratelimit";

const ratelimit = new Ratelimit({
  redis: ...,
  limiter: Ratelimit.slidingWindow(10, "1 m"),
});

const { success } = await ratelimit.limit(userId ?? ip);
if (!success) return new Response("rate limited", { status: 429 });

For signup, Supabase has a native rate-limit toggle in Auth → Policies. Turn it on. Also enable Turnstile / hCaptcha — supabase-js supports it natively now on signUp.

4. CORS wide open — `Access-Control-Allow-Origin: *`

Hit rate: 9 / 9 codebases.

const corsHeaders = {
  "Access-Control-Allow-Origin": "*",
  "Access-Control-Allow-Headers": "authorization, x-client-info, apikey, content-type",
};

Every AI coding assistant ships this snippet as the default. On its own, on a public static endpoint, fine. But when you have:

CORS: * +
An authenticated edge function that accepts the Authorization header +
A logged-in user visiting a malicious page —

…then the malicious page can trigger authenticated calls on behalf of the user. They browse to funny-cat-memes.xyz; in the background their browser fires a DM delete, a subscription upgrade, an AI-credit burn against your app.

Fix: replace * with your app's actual origin (or an allow-list):

const ALLOWED = new Set([
  "https://myapp.com",
  "https://myapp.vercel.app",
]);
const origin = req.headers.get("Origin") ?? "";
const corsHeaders = {
  "Access-Control-Allow-Origin": ALLOWED.has(origin) ? origin : "null",
  ...
};

5. Race conditions on balance / credits / usage counters

Hit rate: 6 / 9 codebases (but 100% of codebases that had any billing / free-tier concept).

Classic pattern:

const { data: usage } = await supabase
  .from("usage_tracking")
  .select("generation_count")
  .eq("user_id", userId)
  .single();

if (usage.generation_count >= 5) {
  return new Response("quota exceeded", { status: 429 });
}

// ... do the expensive AI call ...

await supabase
  .from("usage_tracking")
  .update({ generation_count: usage.generation_count + 1 })
  .eq("user_id", userId);

A user fires 10 requests simultaneously. All 10 read generation_count = 0. All 10 pass the < 5 check. All 10 increment. The user got 10 free AI calls on your dime.

Same pattern shows up on:

Inventory decrements (oversell — sold 10 units, only had 5)
Balance transfers (fire 5 parallel withdrawals of $100 from a $100 account)
Discount code usage (single-use code used 20 times)

Fix: do the check-and-increment atomically in one SQL statement:

UPDATE usage_tracking
SET generation_count = generation_count + 1
WHERE user_id = $1 AND generation_count < 5
RETURNING generation_count;

If the row isn't updated (no rows returned), the user hit their cap. Either use a Postgres function like this called via rpc(), or an UPDATE ... WHERE guard in the edge function. Don't do the check and the update as separate operations.

Why this matters

Each of these issues is not a theoretical risk. On every codebase I audited, at least one of these was exploitable by anyone on the internet today — no special tools, no privileged access. A curious user with a browser console can:

Read all other users' records (pattern 1)
Upgrade their own account to a paid tier without paying (pattern 2)
Drain your AI credits in an afternoon (pattern 3)
Get other users to unknowingly perform actions (pattern 4)
Bypass every usage limit you've tried to enforce (pattern 5)

If you're shipping AI-coded apps, these five are the first pass. They take 2-4 hours to fix if you know what you're looking for.

If you want the list for your codebase specifically — which findings, which files, which lines, with copy-paste fixes for each — that's what VibeScan does. $49, runs on a public GitHub repo, PDF report back in the hour. Most first-time scans on a Lovable/Bolt/v0/Cursor app come back with 1 critical + 5-10 high severity findings, roughly half of which are the patterns above.

Either way: if one of these five rang a bell, go check that code before you close this tab.

Your First Supabase RLS Policy, Without Exposing Your Whole Database

SystAgProject — Sun, 19 Apr 2026 23:35:43 +0000

Every week I audit a handful of AI-generated apps (VibeScan is the service behind this). The single most common "how is this in production" finding is a broken Row Level Security policy. Usually it's one of:

RLS is disabled and the table is just public
RLS is enabled but every policy is USING (true) — so it's still public, it just looks secure
The policy scopes reads correctly, but the UPDATE policy lets users rewrite their own role = 'admin' column

This post is the RLS primer I wish I could hand to every Lovable / Bolt / v0 user on day one. By the end you'll have a correct policy for a "notes" table where each user sees only their own rows, you'll know how to verify it, and you'll recognize the three patterns that break it.

The model

You have a notes table. Each row belongs to one user. Your app should let a signed-in user:

Read only their own notes
Create new notes for themselves
Edit / delete only their own notes

Nobody should be able to read, create for, edit, or delete anyone else's notes. Not even anonymous users. Not even signed-in users who know how to open DevTools.

Here's the schema:

CREATE TABLE public.notes (
  id uuid PRIMARY KEY DEFAULT gen_random_uuid(),
  user_id uuid NOT NULL REFERENCES auth.users(id) ON DELETE CASCADE,
  body text NOT NULL,
  created_at timestamptz NOT NULL DEFAULT now()
);

Step 1 — turn RLS on

RLS is off by default. Turn it on explicitly:

ALTER TABLE public.notes ENABLE ROW LEVEL SECURITY;

The moment you run this, all queries against the table return zero rows — for every user, including authenticated. RLS is deny-by-default; you add policies to carve out what each role can do.

This is a good thing. If you turn RLS on and your app breaks, you now know exactly which tables need policies.

Step 2 — the four policies

One policy per CRUD verb. Each scopes the rows a user can touch.

-- READ: a user sees only their own notes.
CREATE POLICY "notes_select_own"
  ON public.notes FOR SELECT
  TO authenticated
  USING (user_id = auth.uid());

-- INSERT: a user can only create rows under their own user_id.
CREATE POLICY "notes_insert_own"
  ON public.notes FOR INSERT
  TO authenticated
  WITH CHECK (user_id = auth.uid());

-- UPDATE: a user can edit only their own notes, and can't change the owner.
CREATE POLICY "notes_update_own"
  ON public.notes FOR UPDATE
  TO authenticated
  USING (user_id = auth.uid())
  WITH CHECK (user_id = auth.uid());

-- DELETE: a user can delete only their own notes.
CREATE POLICY "notes_delete_own"
  ON public.notes FOR DELETE
  TO authenticated
  USING (user_id = auth.uid());

The difference between USING and WITH CHECK is the subtle part:

USING filters rows you can see for the operation (the "before" predicate).
WITH CHECK validates rows you're trying to write (the "after" predicate).

On UPDATE you need both: USING to decide which rows you can target, WITH CHECK to stop you from flipping user_id to someone else's uid mid-update.

Step 3 — verify the policy actually works

Writing policies is easy. Verifying them is the step most people skip. Supabase ships set role — use it.

-- Pretend to be user A and insert a row
SET LOCAL ROLE authenticated;
SET LOCAL "request.jwt.claims" = '{"sub": "aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa", "role": "authenticated"}';

INSERT INTO public.notes (user_id, body)
VALUES ('aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa', 'hello from A');
-- ✅ succeeds

INSERT INTO public.notes (user_id, body)
VALUES ('bbbbbbbb-bbbb-bbbb-bbbb-bbbbbbbbbbbb', 'malicious row for B');
-- ❌ fails with: "new row violates row-level security policy"

SELECT * FROM public.notes;
-- returns only A's rows, not B's

If you skip verification, you're trusting your mental model. The mental model is wrong more often than you'd think.

The three patterns I keep seeing break

❌ 1. `USING (true)` — "looks like RLS, isn't RLS"

CREATE POLICY "authenticated users can read"
  ON public.notes FOR SELECT TO authenticated
  USING (true);

This is RLS-in-name-only. It lets every signed-in user read every row. If your app has open signup, every visitor can sign up with a throwaway email and read every other user's data.

Fix: USING (user_id = auth.uid()).

❌ 2. UPDATE policy without `WITH CHECK`

CREATE POLICY "notes_update_own"
  ON public.notes FOR UPDATE TO authenticated
  USING (user_id = auth.uid());
  -- no WITH CHECK

The user can update their own row (USING passes), and inside that update flip user_id to another user's id. Now that note belongs to someone else.

Same pattern bites harder on a profiles table that has a role or subscription_tier column. The user can UPDATE their own profile and set role = 'admin'.

Fix: add WITH CHECK (user_id = auth.uid()). On sensitive columns like role or subscription_tier, go further — split them into a separate table that only service_role can write.

❌ 3. Admin actions done from the client

The third pattern isn't an RLS mistake directly — it's a consequence of trying to get around RLS. Someone needs to be able to do something "admin-ish" (mark a payment as completed, promote a user), so they write a policy that lets any authenticated user do the write. Then everyone can.

Fix: keep the RLS policy strict, and move admin actions into a Supabase Edge Function that uses the service_role key. The service_role bypasses RLS by design — that's its job. Just make sure the function itself verifies the caller has the right permission before doing the write.

// edge function
import { createClient } from "npm:@supabase/supabase-js";

const supabase = createClient(
  Deno.env.get("SUPABASE_URL")!,
  Deno.env.get("SUPABASE_SERVICE_ROLE_KEY")!  // bypasses RLS
);

// verify the caller is authenticated *and* has admin role
const jwt = req.headers.get("Authorization")?.replace("Bearer ", "");
const { data: { user } } = await supabase.auth.getUser(jwt);
if (!user) return new Response("unauthorized", { status: 401 });
// check user.app_metadata.role === "admin" or a user_roles table lookup

// now you can do the write that regular authenticated users can't
await supabase.from("payments").update({ status: "completed" }).eq("id", paymentId);

The 10-minute self-audit

Run this against your own Supabase project before you ship:

For every public table, is RLS enabled? (SELECT tablename FROM pg_tables WHERE schemaname = 'public' and check each.)
For every enabled table, are there policies for SELECT / INSERT / UPDATE / DELETE?
Do any policies use USING (true) or WITH CHECK (true)?
On every UPDATE policy, is there a WITH CHECK that prevents ownership / role flipping?
Are there any columns on public-readable tables that shouldn't be readable (Stripe customer IDs, internal notes, moderator flags)? Columns with SELECT granted to authenticated are readable by every signed-in user whose policy match returns a row.

If you want this done automatically on your full codebase — including the 40 other security patterns that show up in AI-generated apps — that's what I built VibeScan for. $49, runs on your public GitHub repo, PDF report with severity-graded findings and copy-paste fixes. Most Lovable / Bolt / v0 / Cursor-built apps come back with 1 critical + 5-10 high severity findings on first scan, and roughly half of them are RLS patterns like the ones above.

Either way — if you've read this far and your app has a USING (true) policy somewhere, go fix it before you close this tab.

The 12 Security Issues I Keep Finding in Vibe-Coded Apps (Lovable, Bolt, v0)

SystAgProject — Sun, 19 Apr 2026 22:12:29 +0000

Over the last few weeks I've been running VibeScan — a security audit tool for AI-generated codebases — against a small set of public Lovable / Bolt / v0 / Cursor apps. Same dozen issues keep surfacing.

If you're shipping a vibe-coded SaaS, run through this list before launch. It'll take you 30 minutes and save you from the most common self-own patterns.

1. Payment webhook has `verify_jwt = false` and no signature check

What you'll find in your repo

# supabase/config.toml
[functions.payment-webhook]
verify_jwt = false

And inside the function, no stripe.webhooks.constructEvent(...) before trusting the event body.

Why it matters. The endpoint is world-reachable. Anyone can curl it with a fake "type": "checkout.session.completed" body and flip a row in your profiles table. Free Pro tier for everyone on the internet.

Fix (one line-change + one env var)

const event = stripe.webhooks.constructEvent(body, signatureHeader, Deno.env.get("STRIPE_WEBHOOK_SECRET"));

2. RLS policies using `USING (true)`

What you'll find

CREATE POLICY "authenticated users can read"
  ON public.cases FOR SELECT TO authenticated
  USING (true);

If cases is "any record" — not "my records" — then any signed-in user reads all the data. Open signup + USING (true) + RLS enabled = a fancy way to display your entire database to any visitor who clicks "Sign up".

Fix: scope by ownership.

USING (user_id = auth.uid())

Then make sure you actually set user_id = auth.uid() on INSERT with a WITH CHECK clause.

3. API keys prefixed with `VITE_` — shipped to every browser

// src/components/ResumeUpload.tsx
const key = import.meta.env.VITE_GEMINI_API_KEY;

Anything with VITE_ / NEXT_PUBLIC_ / REACT_APP_ is in the client bundle. Open DevTools → Network tab → find any request with the key in Authorization → paste it into Postman.

Fix: move the API call to a Supabase Edge Function (or Next.js server route) that holds the key server-side. The browser calls your endpoint; your endpoint calls the vendor.

4. No rate limit on the expensive LLM endpoint

Your generate-something endpoint runs an Opus / GPT-4 call. It accepts an arbitrary-length prompt. There's no cap on requests per user.

Someone writes a while(true) loop in the console. Your monthly AI bill is now $4k.

Fix: two lines with Upstash.

const { success } = await ratelimit.limit(userId);
if (!success) return new Response("rate limited", { status: 429 });

5. Profile row created from the client

// After signUp({ email, password })
await supabase.from("profiles").insert({ id: user.id, name, role: "user" });

The problem isn't the insert. It's that any signed-in user can do an UPDATE with role = "admin" if your RLS policy lets the user write to their own row and the role column isn't excluded.

Fix: move profile creation to a Postgres trigger on auth.users:

CREATE TRIGGER handle_new_user AFTER INSERT ON auth.users ...

And restrict the profiles.role column from client UPDATEs.

6. Subscription tier writable from the client

This is the evil cousin of #5. You have a profiles.subscription_tier column. Your RLS allows UPDATE FOR authenticated USING (user_id = auth.uid()). Any user opens console, runs:

await supabase.from("profiles").update({ subscription_tier: "pro" }).eq("id", myId);

Done. Lifetime Pro access.

Fix: subscription_tier is a server-only column. Update it in a trigger that fires from your payment webhook, and revoke UPDATE on that column from the authenticated role:

REVOKE UPDATE(subscription_tier) ON profiles FROM authenticated;

7. Uploaded files readable by any logged-in user

CREATE POLICY "read uploads"
  ON storage.objects FOR SELECT TO authenticated
  USING (bucket_id = 'case-files');

Anyone who signs up can download every file in the bucket. Particularly painful when the bucket has resumes, medical records, or passport scans.

Fix: encode the user ID in the path and check it in the policy.

USING (bucket_id = 'case-files' AND auth.uid()::text = (storage.foldername(name))[1])

8. Hardcoded `SUPABASE_URL` + anon key as fallbacks

const SUPABASE_URL = import.meta.env.VITE_SUPABASE_URL ?? "https://abc123.supabase.co";

The anon key is technically public (it's designed to be shipped to browsers). But hardcoding it means:

You can't rotate without shipping a new build.
You can't use the same codebase for staging / prod.
If someone ever adds the service_role key by mistake under the same pattern, it's game over.

Fix: throw new Error("missing env var") at build time if the var is missing. No fallback.

9. Weak password policy

<input type="password" minLength={6} />

Six characters is brute-forceable in under a second.

Fix: minLength={10} on the input, and enforce a floor in Supabase Auth settings → Policies → Password requirements. Also turn on the "leaked password check".

10. CORS wide open on server actions

const corsHeaders = {
  "Access-Control-Allow-Origin": "*",
  "Access-Control-Allow-Methods": "POST, OPTIONS",
};

* is correct for static public endpoints. It's not correct for an endpoint that returns user-specific data or does a sensitive action on a cookie-authenticated session. Any site the victim visits can fetch() your API with their creds attached.

Fix: echo the Origin header back only if it matches an allowlist. Or just hardcode your app's domain.

11. No input validation on write endpoints

const { topic, keyMessage, audience } = await req.json();
// straight into the LLM prompt

No zod.parse(...). No length cap. Someone sends a 500 KB prompt. Your model call burns $3 and times out. Multiply by 10k loops.

Fix:

const schema = z.object({
  topic: z.string().max(500),
  keyMessage: z.string().max(500),
  audience: z.string().max(100),
});
const parsed = schema.parse(await req.json());

12. Credits / balance updates that aren't atomic

const { credits } = await supabase.from("users").select("credits").eq("id", userId).single();
if (credits > 0) {
  await doTheExpensiveThing();
  await supabase.from("users").update({ credits: credits - 1 }).eq("id", userId);
}

Classic race. User fires two parallel requests, both read credits = 1, both proceed, both decrement. One free call. In the worst case, it's 50 parallel calls for one credit.

Fix: atomic decrement in a single statement (or a Postgres function):

UPDATE users SET credits = credits - 1 WHERE id = $1 AND credits > 0 RETURNING credits;

If the returned row is empty, reject the request.

How to check your own repo in 5 minutes

Manual approach: grep the repo for these patterns.

verify_jwt = false in supabase/config.toml
USING (true) in *.sql
VITE_.*_KEY / NEXT_PUBLIC_.*_KEY / REACT_APP_.*_KEY in source
minLength={6} in auth forms
Access-Control-Allow-Origin: * in server functions
corsHeaders without an allowlist

If you want a cleaner version of the above as a per-repo PDF with every finding graded and a copy-paste fix for each, that's what VibeScan is. It clones your repo, runs a multi-batch audit with Claude Opus 4.7, and spits out a severity-graded report. $49 one-time. Typical finding count for a 3-month-old vibe-coded app is 6-15 issues, 1-2 of them critical.

If you want me to run it on your repo for free in exchange for feedback, reply to me on Twitter/X or send me the repo URL.

Stay safe out there.

I ran a security audit on my own Python codebase with an LLM for $0.90. Here is what it found.

SystAgProject — Sun, 19 Apr 2026 21:35:06 +0000

Last week I shipped a small product called VibeScan — a 49-dollar PDF security audit for apps built with Lovable / Bolt / Cursor / Replit / v0. Before I asked anyone to pay for it, I ran it on my own codebase as a smoke test.

124 scannable Python files, 4 LLM batches, 22 seconds total wall time. Audit cost: $0.90 of Opus 4.7 with prompt caching. Output: 0 critical findings, 1 high, 2 medium. One of the findings was a real bug I fixed the same hour. The other two were legitimate risk flags I had not thought about.

Here is the full report, with context on each finding.

[HIGH] Subprocess stdout/stderr written to the ledger without size cap

Location: — the function that spawns every scheduled job.

A runaway script that prints megabytes of logs (for example a scraper dumping HTML) will push all of that into your SQLite ledger, potentially bloating the database and causing memory issues during capture. A single bad run could write hundreds of MB.

Fix: In , truncate stdout/stderr to the last ~10KB before returning (e.g., ) so oversized output cannot blow up the ledger or memory.

Why this matters

I was using Python subprocess.run with . That flag tells Python to hold the subprocess full stdout and stderr in memory until the child exits. Which is fine when a cron job prints 50 lines and exits. But if one of those jobs is a web scraper that dumps the HTML of every page it visits, or an ETL that prints a row per record processed on a million-row table, every byte of that output sits in the scheduler process RAM before being written to the SQLite ledger.

I had never thought about it. The scheduler had run for weeks without hitting this because all the current jobs are well-behaved. But the next job anyone adds could be the one that dumps 500 MB on a bad day.

The fix took four minutes: cap each stream at 50 KB before returning. If a security auditor had flagged this I would have paid $200. VibeScan cost $0.90 for the whole repo.

[MEDIUM] Gmail OAuth refresh token stored in plaintext

Location: line 30 — the function that loads Google OAuth credentials.

The Gmail refresh token is saved as a plain JSON file on disk. Anyone who can read that file (backup, stolen laptop, server compromise) gains indefinite access to send and read email as the account owner — refresh tokens do not expire.

Fix: At minimum, ensure credentials/ is in .gitignore and file permissions are 0600; for stronger protection, encrypt the token at rest (for example via OS keyring or an encrypted env var) and document revocation via Google Account -> Security -> Third-party apps.

Classic defense-in-depth issue. No immediate exploitation, but the kind of thing you kick yourself over if it ever leaks.

[MEDIUM] HTML email bodies stripped with naive regex

Location: line 215 — the function that normalizes inbound email.

extract_plain_body uses a regex to strip HTML tags from inbound mail, which can leave script/style contents, encoded entities, or malformed markup in the plain text the classifier sees. If that text is later fed into an LLM prompt or surfaced to a user, attacker-crafted emails can smuggle content that was not visible as HTML.

The inbound email pipeline feeds the plain text version into an LLM classifier (to route support emails). Because downstream is an LLM, this is a prompt injection surface. A sophisticated spammer who knows we route email via LLM can craft HTML with hidden content in style tags or HTML comments that appears empty to a human recipient but becomes visible instructions in the LLM input.

Not exploited today. But it is the exact class of bug that becomes headline news in 18 months, and the fix is a 20-line swap to BeautifulSoup.

What this scan cost and what it missed

Input tokens: 176,364 with prompt caching across 4 batches
Output tokens: 779
Wall time: 22 seconds
Direct infrastructure cost: $0.90

Consultant equivalent would be 3-5 hours on a 124-file repo, billed $600-1500, producing a report that needs translation by an engineer to be actionable. The VibeScan report is in the language the buyer speaks and includes the exact line to change.

What the scan missed (honest limitations)

Business logic flaws like a checkout that trusts client-side prices.
Concurrency issues in state updates (requires runtime tracing, not static read).
Dependency vulnerabilities — we do not cross-reference package.json against CVE databases. Snyk does that better.
Production infra — we scan the code, not deployed infrastructure.

For a solo founder running an AI-coded app, the findings VibeScan catches are where the actual failures come from. For enterprise eng teams with dedicated security engineers, Snyk plus manual review plus threat modeling is the better playbook.

Try it on your own repo

If you shipped something with Lovable / Bolt / Cursor / Replit / v0 and you are about to take real money from real users — get a second set of eyes on the code first.

$49, one-time, PDF in ~10 minutes: systag.gumroad.com/l/vibescan

First 10 readers of this post get it for free — DM me the repo URL and I will send the PDF back within the day.

DEV Community: SystAgProject

I Audited 9 Vibe-Coded Apps in 24 Hours. Here Are the 5 Patterns That Show Up Every Single Time.

1. RLS policies with USING (true) — "looks secure, isn't"

2. Unauthenticated edge functions — "verify_jwt = false"

3. No rate limit on AI / generation / contact / signup endpoints

4. CORS wide open — Access-Control-Allow-Origin: *

5. Race conditions on balance / credits / usage counters

Why this matters

Your First Supabase RLS Policy, Without Exposing Your Whole Database

The model

Step 1 — turn RLS on

Step 2 — the four policies

Step 3 — verify the policy actually works

The three patterns I keep seeing break

❌ 1. USING (true) — "looks like RLS, isn't RLS"

❌ 2. UPDATE policy without WITH CHECK

❌ 3. Admin actions done from the client

The 10-minute self-audit

The 12 Security Issues I Keep Finding in Vibe-Coded Apps (Lovable, Bolt, v0)

1. Payment webhook has verify_jwt = false and no signature check

2. RLS policies using USING (true)

3. API keys prefixed with VITE_ — shipped to every browser

4. No rate limit on the expensive LLM endpoint

5. Profile row created from the client

6. Subscription tier writable from the client

7. Uploaded files readable by any logged-in user

8. Hardcoded SUPABASE_URL + anon key as fallbacks

9. Weak password policy

10. CORS wide open on server actions

11. No input validation on write endpoints

12. Credits / balance updates that aren't atomic

How to check your own repo in 5 minutes

I ran a security audit on my own Python codebase with an LLM for $0.90. Here is what it found.

[HIGH] Subprocess stdout/stderr written to the ledger without size cap

Why this matters

[MEDIUM] Gmail OAuth refresh token stored in plaintext

[MEDIUM] HTML email bodies stripped with naive regex

What this scan cost and what it missed

What the scan missed (honest limitations)

Try it on your own repo

1. RLS policies with `USING (true)` — "looks secure, isn't"

4. CORS wide open — `Access-Control-Allow-Origin: *`

❌ 1. `USING (true)` — "looks like RLS, isn't RLS"

❌ 2. UPDATE policy without `WITH CHECK`

1. Payment webhook has `verify_jwt = false` and no signature check

2. RLS policies using `USING (true)`

3. API keys prefixed with `VITE_` — shipped to every browser

8. Hardcoded `SUPABASE_URL` + anon key as fallbacks