VIBE HACKING: HOW ATTACKERS EXPLOIT AI-GENERATED APPS | VIBEEVAL

Why vibe-coded apps are easy targets

AI coding tools generate predictable patterns. Once you have seen one Lovable app, you have seen them all. The same Supabase key exposure, the same missing RLS, the same client-side auth. Attackers know these patterns and scan for them at scale.

The asymmetry is brutal: a defender must secure every table, function, and dependency; an attacker needs one open path. Generators expand defender surface faster than most teams expand review capacity. Vibe hacking is the name for exploiting that asymmetry as a productized playbook rather than artisanal hacking.

Vibe hacking is not magic AI malware. It is classic web and API abuse aimed at a generation of apps that share scaffolding, naming, and security blind spots. Speed-to-demo tools reward “it works” over “it authorizes.” Criminals and researchers both notice.

This page maps common attack vectors, how they work step by step, defender playbooks, and fix patterns. Use it to red-team your own product with authorization — not to attack third parties.

Common Attack Vectors

Exposed Supabase / Firebase keys

View page source, grab the anon (or worse, service) key, and query the database directly. Most vibe-coded apps have weak or missing Row Level Security / security rules, so every table is readable or writable.

How it works

1. Open browser DevTools on any page (Network or Sources).
2. Search for supabase, firebase, anon, or eyJ (JWT prefix) in bundled JS.
3. Use the public project URL and API key to call REST or SDK endpoints directly.
4. Read, modify, or delete data when policies/rules are missing or true.

Why AI apps fail here

Generators correctly embed the anon key in the client (expected for Supabase) but skip RLS. Firebase apps leave test-mode rules. Service role keys sometimes land in VITE_ / NEXT_PUBLIC_ env by mistake — that is a full bypass.

Defender playbook

• Assume anon keys are public; protect data with RLS / Firebase rules (Supabase RLS guide, Firebase security rules).
• Grep bundles and repos for service_role, sk_live, Firebase admin credentials.
• Rotate any secret that was ever client-shipped; monitor PostgREST logs for bulk select.
• Run token leak checker and Supabase RLS checker.

Fix pattern

alter table profiles enable row level security;

create policy "users read own profile"
  on profiles for select
  using (auth.uid() = id);

create policy "users update own profile"
  on profiles for update
  using (auth.uid() = id)
  with check (auth.uid() = id);

Client-side auth bypass

AI tools generate auth guards in React components but skip server-side checks. Delete the guard in DevTools — or ignore the UI entirely — and call the API.

How it works

1. Navigate to a protected page and observe the redirect when logged out.
2. Open DevTools and modify auth state in localStorage, cookies, or client context — or skip the UI.
3. Call the API endpoint directly without auth headers / with another user’s id in the body.
4. Access admin panels, user data, or payment information if the server trusts the client.

Defender playbook

• Every Edge Function, serverless route, and RPC verifies JWT and authorization, not just “token present.”
• Never trust user_id or role from the request body; take identity from the verified token.
• Test with Burp/ZAP or curl while logged out and as a second user.
• See authentication implementation and auth flow patterns.

Fix pattern (Edge Function sketch)

import { createClient } from "https://esm.sh/@supabase/supabase-js@2";

Deno.serve(async (req) => {
  const authHeader = req.headers.get("Authorization");
  if (!authHeader) return new Response("Unauthorized", { status: 401 });

  const supabase = createClient(
    Deno.env.get("SUPABASE_URL")!,
    Deno.env.get("SUPABASE_ANON_KEY")!,
    { global: { headers: { Authorization: authHeader } } }
  );

  const { data: { user }, error } = await supabase.auth.getUser();
  if (error || !user) return new Response("Unauthorized", { status: 401 });

  // Use user.id for queries — never body.userId from the client alone
  const { data, error: qErr } = await supabase
    .from("orders")
    .select("*")
    .eq("owner_id", user.id);

  if (qErr) return new Response("Error", { status: 500 });
  return Response.json(data);
});

API endpoint enumeration

AI-generated APIs follow predictable naming. Guess /api/users, /api/admin, /api/payments and find unprotected endpoints.

How it works

1. Check the network tab for API calls during normal usage.
2. Try common endpoint names: /api/users, /api/orders, /api/config, /api/admin, /functions/v1/....
3. Observe which endpoints return data without authentication.
4. Access other users’ data by changing ID parameters (leads into IDOR).

Defender playbook

• Inventory all routes; default deny.
• Authn + authz middleware on every mutating and sensitive read path.
• Do not ship OpenAPI/Swagger publicly without auth (GraphQL/Swagger exposure).
• Rate limit and log 401/403 spikes (API abuse protection).

IDOR exploitation

Sequential or predictable IDs in URLs let anyone access other users’ resources. Change /api/users/1 to /api/users/2 and read their profile.

How it works

1. Find any URL or API call with a numeric or predictable ID.
2. Increment or decrement the ID (or swap UUIDs collected from other responses).
3. Observe that the server returns another user’s data.
4. Automate extraction across the ID space.

This is BOLA in OWASP API terms — endemic in AI CRUD. Details: BOLA in AI-generated CRUD.

Defender playbook

• Server checks resource.owner_id == auth.uid (or RLS equivalent) on every read/update/delete.
• Prefer opaque IDs; never rely on “hard to guess” as authz.
• Automated tests: user A creates object; user B’s token must get 404/403.
• Full scan categories covering object-level auth in vibe code scanner.

Fix pattern

// BAD
const order = await db.orders.findById(req.params.id);

// GOOD
const order = await db.orders.findFirst({
  where: { id: req.params.id, ownerId: req.user.id },
});
if (!order) return res.status(404).end();

Payment flow manipulation

Vibe-coded payment flows often validate price or “paid” status on the client. Intercept the request to change the price, skip the payment step, or replay a successful transaction.

How it works

1. Start a checkout flow and intercept the API request.
2. Modify the price field, paid: true, or remove payment verification.
3. Submit the modified request.
4. Receive the product or service without paying — if the server trusts the client.

Defender playbook

• Create prices and payment intents server-side with Stripe (or equivalent); client only confirms.
• Fulfill only after verified webhook signatures (Stripe webhook pattern).
• Idempotency keys; reject replayed events.
• Never trust client-supplied amount for fulfillment.

Dependency confusion / package hallucination

AI hallucinates package names that do not exist. Attackers register that name on npm with malicious code and wait for npm install.

How it works

1. Find AI-suggested packages that do not exist on the registry (or typosquat popular ones).
2. Register the package name with a postinstall payload.
3. When the developer runs npm install, attacker code executes.
4. Exfiltrate environment variables, secrets, and tokens.

See package hallucination scanner and poisoned CI patterns.

Defender playbook

• Verify every new dependency exists, has a maintainer history, and matches the intended library.
• Pin versions; use lockfiles; enable npm provenance where available.
• Block postinstall scripts in CI when possible; review exceptions.
• Never copy npm install lines from chat without registry checks.

Bonus vectors attackers chain

• Open Storage buckets — public list/download of user uploads.
• SSR / preview deploys with prod secrets — one preview URL = prod data.
• Mass signup / OTP abuse — no rate limits on auth endpoints.
• Prompt injection against admin copilots — less common in pure CRUD apps, relevant when apps embed LLMs (indirect prompt injection).
• Platform fingerprinting — Lovable detector-style signals to build target lists.

Tools most targeted by vibe hackers

Lovable

Full Supabase stack exposed in many apps. Public anon keys + missing RLS = open database. Documented mass findings (170+ DBs in Feb 2026). High fingerprintability. Guides: Is Lovable Safe?, Lovable security scanner.

Why hunters like it: one recon path works on thousands of hosts; showcase galleries and lovable.app DNS make discovery trivial.

Bolt.new

Deploys instantly with secrets in environment variables that sometimes leak to the client. Serverless functions often ship without auth. Template monoculture. Is Bolt Safe?

Why hunters like it: preview URLs and Netlify/Vercel function shapes are guessable; secret-in-VITE_ is a single grep away.

Replit

Public repos by default in many workflows. Secrets in .env that get forked and exposed. Always-on URLs invite scanning. Is Replit Safe?

Why hunters like it: forks duplicate secrets; always-on means the window never closes.

v0

Frontend-first generation. Server Components mixed with client security assumptions; auth gaps when backend is bolted on later. Is v0 Safe?

Why hunters like it: Vercel previews + server actions create a large URL space that looks “internal” but is public.

Cursor / Windsurf / Copilot-assisted custom stacks

Less “one template,” same bug classes when agents scaffold Supabase/Firebase quickly. Risk scales with unreviewed Composer/Cascade commits.

Why hunters like it: diversity of stacks is offset by monoculture of mistakes — BOLA and missing middleware repeat regardless of framework fashion.

Attacker automation (what defenders should assume)

At scale, vibe hacking looks like:

discover hosts (fingerprints, DNS, showcases)
  → extract project URL + anon key from JS
  → probe REST for open tables
  → dump PII / swap IDs for IDOR
  → hit /functions/v1/* without auth
  → optional: payment and admin path fuzz

If your defense requires “nobody will notice our obscure subdomain,” you are already late. Defense is policy and server checks, not obscurity.

How to defend against vibe hacking

Scan before you ship

Run an automated security scan on every deployment. Catch exposed keys, missing auth, and open endpoints before attackers do. Wire preview URLs into CI (CI/CD security guide).

Enable Row Level Security / Firebase rules

If you use Supabase or Firebase, configure policies for every table and bucket. Your anon key will always be public. Rules are what protect the data.

Add server-side authz

Never trust client-side auth alone. Validate tokens and permissions on every API endpoint, not just in React components.

Audit your dependencies

Check that every npm package the AI suggested actually exists and is maintained. Remove packages you do not need.

Test your payment flow

Try to bypass your own checkout. Modify prices, skip steps, replay transactions. If you can do it, attackers will.

Rate limit and monitor

Auth and expensive AI proxy routes need limits and alerts (API abuse protection).

Least privilege secrets

Separate staging and production. No service role in browsers. Rotate after any exposure.

Continuous regression

AI “quick fixes” re-open policies. Re-scan after every major prompt session. Longitudinal failure is common — see Lovable regression research on the site under data studies.

Economics of vibe hacking

Traditional targeted intrusion against a well-run bank is expensive. Scraping a thousand Lovable apps for open profiles tables is cheap:

When the marginal cost of the next victim is near zero, assume automation. Your app does not need to be famous; it needs to match a fingerprint and fail a probe.

Staging, demos, and “temporary” holes

Vibe hackers love:

• Demo days with RLS off “so judges can click around”
• Staging on a public URL with production snapshots
• README badges linking to live apps still on default policies
• Product Hunt launches that spike traffic and scanner interest the same week

A temporary hole on a public URL is a permanent copy in someone’s dataset. Ship demo accounts with seed data and locked policies instead of open tables.

Chained kill chain (composite)

Representative chain seen across AI apps:

1. Fingerprint Lovable or Vite+Supabase.
2. Extract anon key; OpenAPI lists users, messages, payments.
3. users closed; messages open → scrape emails and reset-adjacent content.
4. Password reset tokens or magic links appear in support tables → account takeover.
5. Session used against /functions/v1/admin-sync with no JWT check → privilege.
6. Export billing CSV → fraud / extortion.

Root cause is often one missing policy plus one unauthenticated function. Fix both classes, not only the table that made the news.

What vibe hacking is not

• Not “AI that hacks better than humans” as a sci-fi agent (though agents help attackers write scripts faster).
• Not zero-days in React or Supabase platform code as the default path.
• Not only “script kiddies” — researchers, competitors, and criminals use the same playbooks with different ethics.

Defenders who wait for novel exploits while leaving USING (true) live are optimizing the wrong threat.

Red-team exercise for your own app (authorized)

Time-box two hours:

1. From a clean browser profile, extract every key and URL from your production JS.
2. Without logging in, hit REST/Storage/Functions.
3. With user A and user B, swap every id you see in the network tab.
4. Intercept checkout; try client-side price and paid flags.
5. List npm packages added in the last month; verify registry provenance.
6. File findings as tickets with severity; fix criticals before new features.

If this exercise feels unfair, good — attackers do not play fair.

Monitoring signals that imply active vibe hacking

• Burst of PostgREST traffic with select=* and high Range headers
• Many 401/403 from a single ASN then a successful bulk 200 on one table
• Signup spikes with sequential emails / + aliases
• Edge Function invocations without Authorization
• Sudden Storage bandwidth from unknown referrers

Pipe Supabase/host logs to something you actually alert on. Dashboard vibes are not detection.

Legal and ethical boundary (again)

This page documents offense for defense and authorized testing. Unauthorized access is a crime in most jurisdictions. If you find a stranger’s open database, use responsible disclosure channels — do not “browse a little.” If you run a scanner product or bounty, stay inside program rules and rate limits.

Defender checklist (copy into PR template)

• RLS/rules enabled and tested for owner vs stranger vs anon
• No service role / payment secrets in client bundle
• API and Edge Functions verify JWT + object ownership
• Storage not public for private objects
• New dependencies verified on registry
• Webhooks signature-verified
• Rate limits on login, signup, AI routes
• Preview and prod scanned
• Demo/staging not using open policies or prod PII
• Logs/alerts for bulk select and auth anomalies

Related Resources

• Vibe Coding Security Risks — Complete list of risk categories in AI-generated apps
• Common Security Flaws — Code examples of each vulnerability with secure alternatives
• Penetration Testing Guide — How to test your own app like an attacker would
• Token Leak Checker — Check if your API keys and tokens are exposed
• Vibe Code Scanner — Multi-platform live probe
• Lovable Detector — Fingerprint Lovable apps before deep testing

Blue-team detection ideas

• Alert on PostgREST queries with huge select and no filters from many IPs.
• Alert on spikes of 401 across /auth.
• Canary rows in sensitive tables — if read, page someone.
• WAF rate limits on /rest/v1 and /functions/v1.

Purple-team exercises (authorized)

Quarterly: give an engineer only the production URL and two hours to find one critical without source. If they succeed, the gate failed. Fix and repeat.

Release evidence pack

Operator habits that compound

Operational checklist for vibe-hacking (1)

Common AI-generator mistakes on vibe-hacking (2)

Verification commands and proofs (3)

CI and release gates (4)

Environment separation (5)

Logging, monitoring, and abuse (6)

Dependency and supply chain (7)

Human process and training (8)

Operational checklist for vibe-hacking (9)

Common AI-generator mistakes on vibe-hacking (10)

Verification commands and proofs (11)

CI and release gates (12)

Environment separation (13)

Logging, monitoring, and abuse (14)

Dependency and supply chain (15)

Test your app before hackers do

VibeEval runs the same class of checks attackers automate — exposed keys, missing auth, open endpoints, IDOR — and shows you what to fix. Predictable offense deserves predictable defense: scan the live URL, lock the data plane, and stop trusting the client.