Vibe Pentesting: Security Testing for Vibe-Coded Apps

What is vibe pentesting?

Vibe pentesting is penetration testing tailored to apps built with AI coding tools - the class of software produced by Lovable, Bolt, Cursor, Claude Code, v0, Replit, Base44, Figma Make, and Windsurf. It narrows the scope from general-purpose pentesting to the specific failure modes these tools consistently ship, which means faster turnaround, lower cost, and coverage of the issues most likely to bite a vibe-coded app in production.

Vibe-coded apps don’t fail randomly. They fail in patterns. The generator determines the pattern. That is what makes this kind of pentesting scannable.

Design goals

1. Outside-in - no privileged agent install required for the default scan; attackers do not get your source either.
2. Generator-aware - fingerprint first, then apply the matching failure checklist.
3. Evidence-first - every critical includes a reproducible request, not a vibes-based warning.
4. Fix-forward - prompts paste back into the same AI tool that introduced the bug.
5. Continuous - cheap enough to run on every deploy, not once a year.

Those goals trade breadth of exotic vulns for depth on the boring ones that pay ransoms and breach notifications.

Why traditional pentesting misses the target for vibe-coded apps

Traditional pentesting assumes the code was written by humans with inconsistent, independently-invented decisions. That is the right model for most software. It is the wrong model for AI-generated apps, where the same tool produces the same mistakes across every project.

A traditional pentest engagement takes one to three weeks, costs $5,000–$50,000, and delivers a report that spans OWASP Top 10, business logic, and edge cases. For a vibe-coded MVP that changed last week and will change again tomorrow, that cadence is wrong: by the time the report lands, the app is different.

Vibe pentesting inverts the tradeoff. Narrow scope, seconds-long runtime, continuous re-scan on every deploy. For the 95% of issues that matter in vibe-coded apps, it is the right shape of testing.

The vibe pentest checklist

The short list of issues that actually land in production vibe-coded apps:

1. Missing Row Level Security on Supabase or Firebase tables - the single most common and most severe finding
2. Exposed API keys in the frontend bundle (Stripe secret, Firebase service account, OpenAI, Anthropic, AWS)
3. BOLA / IDOR on generated CRUD endpoints - change an ID, read someone else’s data
4. Auth flows that verify the user but skip role or ownership checks
5. Open storage buckets on Supabase Storage, Firebase Storage, or S3
6. Permissive CORS (* with credentials) on endpoints returning sensitive data
7. Debug routes or admin panels that shipped to production
8. Webhook endpoints without signature verification
9. Input validation skipped - SQL injection, XSS, prompt injection
10. Missing security headers - CSP, HSTS, X-Frame-Options

Every finding from that list is scannable from outside the app. That’s why vibe pentesting can be automated in a way traditional pentesting cannot.

How a vibe pentest runs

1. Scope - paste the deployed URL. No access credentials, no source code access, no agent to install.
2. Recon - the scanner loads the app in a headless browser, captures every asset and request, and maps the API surface.
3. Probe - each endpoint is tested for the checklist above, with evidence captured for every finding.
4. Report - findings ranked by severity, each with evidence, exploitation notes, and a fix prompt for your AI coding tool.
5. Rescan - re-run after fixes ship to verify nothing regressed.

The 14-pattern vibe-coding bug taxonomy

Vibe-coded apps fail along a known list of patterns. The full taxonomy is in Vibe-Coding Vulnerabilities; the shortlist that drives a vibe pentest:

1. Missing RLS / Firestore Rules - the biggest one, by impact and frequency.
2. Service-role key in the bundle - total database compromise in one finding.
3. Hardcoded admin email gating - frontend-only, server has no idea.
4. Mass assignment on profile / settings updates - role: admin in a PATCH body.
5. BOLA on generated CRUD - change the ID, read the next person’s row.
6. Public storage buckets - anonymous list, anonymous read, sometimes anonymous upload.
7. Webhook without signature verification - Stripe, Resend, Linear, GitHub.
8. LLM proxy without prompt-injection guardrails - system prompt leaks, tool poisoning.
9. Hallucinated dependencies - npm packages that do not exist, squatted by attackers.
10. Source maps in production - exposes the full unminified codebase including comments.
11. Verbose error responses - stack traces, env var names, sometimes raw secrets.
12. Permissive CORS with credentials - every site can read your authenticated responses.
13. JWT signed with a leaked or weak secret - forge admin tokens trivially.
14. Local storage as session store - any XSS becomes full session theft.

A vibe pentest probes for every pattern. The scanner-grade subset is also covered by Vibe Code Scanner, the Token Leak Checker, the Supabase RLS Checker, the Firebase Scanner, the Package Hallucination Scanner, and the Security Headers Checker.

Vibe pentest vs traditional pentest

The two are not substitutes. For anything touching sensitive data, run a vibe pentest continuously and a human pentest annually. For unregulated MVPs, continuous vibe pentesting alone is the pragmatic floor.

Per-tool variants

The methodology is the same. The fingerprint, the failure shape, and the fix-prompt target differ per tool. Below are the things a vibe pentest does differently for each.

Lovable

• Stack: React + Supabase. Sometimes Lovable Cloud (Edge Functions) or Lovable Connect (third-party integrations).
• Where it fails: RLS on tables added in follow-up prompts. Edge Functions that run as service-role with no auth check. Webhook handlers without signature verification.
• What the pentest does differently: enumerates Supabase tables via the PostgREST OpenAPI endpoint. Fingerprints lovable-tagger. Tests every Edge Function URL as anon and as non-admin user.
• Fix-prompt target: Lovable’s chat interface or a connected Cursor / Claude Code session. See Lovable Pentesting and Lovable Safety Guide.

Cursor

• Stack: Anything - Cursor is a code editor, not a generator with a fixed stack. Most common: Next.js + Postgres/Supabase, or Python FastAPI.
• Where it fails: the AI happily writes code that uses environment variables but never tells the user which variables are server-only. Secrets ship to client bundles via misuse of NEXT_PUBLIC_*. SSRF in fetch-URL features. Mass assignment.
• What the pentest does differently: harder fingerprint (no telltale artifact), so the scanner falls back on framework detection. Runs the full vibe checklist with no Cursor-specific shortcut.
• Fix-prompt target: Cursor itself, with the finding pasted into the chat alongside @Codebase for context. See Cursor Safety Guide.

Bolt (StackBlitz)

• Stack: Vite + React/Vue + chosen backend. Often deployed via Bolt’s hosted preview or to Netlify/Vercel.
• Where it fails: preview deployments left public with debug toggles. CORS set to * because Bolt’s local dev needed it and no one closed it down for prod. Hardcoded mock data that is actually real test PII.
• What the pentest does differently: specifically checks Bolt-style preview URLs (*.stackblitz.io, *.bolt.new) for production-grade configuration. Looks for debug routes (/__debug, /_dev).
• Fix-prompt target: Bolt’s chat. See Bolt Safety Guide.

v0 (Vercel)

• Stack: Next.js + Tailwind, almost always deployed to Vercel. Often paired with Supabase or Postgres on Neon.
• Where it fails: server actions without authentication checks. Server components that fetch with a server-only API key but expose the result to the client unfiltered. Open Vercel preview URLs that index in Google.
• What the pentest does differently: specifically checks Vercel preview/branch URLs and vercel.app subdomains. Tests every server action URL (/_next/...) as anon. Looks for indexed preview deployments via search.
• Fix-prompt target: v0’s chat or paste into Cursor/Claude Code on the cloned repo. See v0 Safety Guide.

Replit

• Stack: Anything - Replit hosts Python, Node, Go, Ruby. Replit Database is the closest thing to a default backend. Many Replit apps deploy to repl.co subdomains.
• Where it fails: Replit Database has no RLS concept; every key is readable by code that has the secret. Apps frequently expose admin endpoints under /admin with no auth at all. Replit Agent sometimes hardcodes secrets directly into source.
• What the pentest does differently: harder to test backends that are not Supabase or Firebase, so the scanner relies on direct endpoint probing. Looks for repl.co subdomain patterns and applies higher suspicion to debug routes.
• Fix-prompt target: Replit Agent or the editor. See Replit Safety Guide.

Claude Code

• Stack: Anything. Claude Code is a CLI agent - the user picks the stack.
• Where it fails: Claude Code is the most “what you asked for” of the AI tools - it implements exactly what the prompt says, including the security shortcuts the prompt did not exclude. Apps generated with vague security requirements ship vague security. Specific failures: Edge Functions that work locally but were never deployed with the right env vars, leading to “the auth check returns true if the env is missing” patterns.
• What the pentest does differently: runs the full checklist, no shortcut. Particular attention to the integration layer (third-party APIs, webhooks) because Claude Code is most often used to wire integrations.
• Fix-prompt target: Claude Code itself. See Claude Code Safety Guide.

Windsurf

• Stack: Anything (Codeium’s editor with agentic features). Most common: Next.js or Python.
• Where it fails: similar to Cursor - context-blindness on which files run server vs client. Cascade-mode multi-file changes that introduce secret leakage across modules.
• What the pentest does differently: runs the full checklist. Looks for cascade-pattern leakage (a secret defined in one file and imported into a client-side file).
• Fix-prompt target: Windsurf Cascade. See Windsurf Safety Guide.

GitHub Copilot

• Stack: Anything. Copilot is autocomplete + Workspace + agent modes inside the IDE.
• Where it fails: silently accepts insecure defaults from the surrounding code. If your codebase has one anti-pattern (skipping CSRF, no input validation), Copilot will replicate it across every new file.
• What the pentest does differently: treats Copilot-built apps as “human + a force-multiplier for whatever the human’s existing patterns are.” Runs the full checklist with extra weight on consistency checks (the same bug repeated across endpoints).
• Fix-prompt target: Copilot Chat or directly in the editor. See GitHub Copilot Safety Guide.

Devin

• Stack: Anything. Devin is an agentic engineer that takes a ticket and ships a PR.
• Where it fails: Devin generates code that passes its own tests but does not threat-model the change. Ships features with the security bugs already discussed in the ticket as features rather than as bugs. Particularly weak on secret-management discipline.
• What the pentest does differently: because Devin shipped a PR, the diff is auditable. The pentest applies the full checklist and pays special attention to any new endpoint, new env var, or new dependency introduced by the PR.
• Fix-prompt target: Devin in a follow-up ticket. See Devin Safety Guide.

Vibe pentest in CI/CD

The right place to run a vibe pentest is on every deploy. The wiring:

# .github/workflows/security.yml - sketch, not a full file
name: vibe-pentest
on:
  deployment_status:
    types: [success]

jobs:
  pentest:
    runs-on: ubuntu-latest
    steps:
      - name: Run vibe pentest
        run: |
          curl -sS -X POST https://api.vibe-eval.com/scan \
            -H "Authorization: Bearer ${{ secrets.VIBEEVAL_KEY }}" \
            -d '{"url":"${{ github.event.deployment_status.target_url }}"}' \
            > scan.json
      - name: Block on Critical findings
        run: |
          test $(jq '.findings[] | select(.severity=="Critical") | length' scan.json) -eq 0

Pattern: deploy succeeds → scan fires → fail the workflow if any Critical lands. Notify on Slack with the scan URL. Critical issues block the next deploy until rescan passes.

For larger teams: gate the deploy itself rather than the post-deploy alert. Scan the staging environment first; only promote to prod after a clean scan.

“AI builds it, AI pentests it, AI fixes it” feedback loop

The right loop is now end-to-end agentic:

1. AI tool builds the app. Lovable, Cursor, Claude Code, v0 - pick one.
2. AI agent pentests the deployed URL. The vibe pentest from this article.
3. AI fix prompt is generated for each finding. Severity, evidence, root cause, the exact prompt to paste back into the originating tool.
4. AI tool patches. Paste the fix prompt. Apply the diff. Deploy.
5. AI agent rescans. Verify the finding is closed. New findings introduced by the patch are also caught.
6. Loop continues. On every subsequent deploy.

The economic insight: every step is now sub-dollar in cost and sub-minute in latency. The human’s role moves from “find and fix bugs” to “review the patches and ship them.” The bottleneck is review, not work.

The risk: if step 3 generates a bad fix prompt, step 4 ships a worse bug. That is why every patch should still pass through a human review on the first iteration, even if subsequent iterations are auto-merged. See Integration Layer Is the Real Security Gap for the case for human gates on integration code.

Anonymized findings - what vibe pentests catch

A representative cross-section of findings from vibe-coded apps we audit. Each is generalized.

Finding A - Anon-readable users table on a Cursor + Supabase app

• Endpoint: /rest/v1/users
• Evidence: Anonymous GET returned every row including email, password reset tokens, last login.
• Impact: Full PII disclosure for every user.
• Fix: Enable RLS, write per-user policies, audit every other table the same way.

Finding B - OpenAI key leaked through a v0 server action error

• Endpoint: POST /api/chat (Next.js route handler)
• Evidence: Sending a malformed body crashed the handler. The error response body included the raw exception, which contained Authorization: Bearer sk-ant-... from the upstream fetch.
• Impact: Stolen API key, attacker-funded LLM access.
• Fix: Wrap the upstream fetch in a try/catch, return a generic 500 with no detail, log the actual error server-side only.

Finding C - Stripe webhook unverified on a Lovable Edge Function

• Endpoint: POST /functions/v1/stripe-webhook
• Evidence: The function parsed event.type from the JSON body and updated user subscription state. No signature verification.
• Impact: Forged events upgrade any user to paid plan.
• Fix: Use stripe.webhooks.constructEvent with the raw body and the webhook secret. Add a regression test.

Finding D - Hardcoded admin email list in a Bolt + React app

• Endpoint: /admin/* routes and /api/admin/* handlers
• Evidence: Frontend bundle contained const ADMINS = ['founder@example.com'] and gated routes on it. The corresponding API handlers performed no server-side check.
• Impact: Any authenticated user can hit admin APIs directly with curl.
• Fix: Move admin status to a server-validated role field. Check on every admin endpoint.

Finding E - Public Firebase Storage bucket on a Replit + Firebase app

• Endpoint: https://firebasestorage.googleapis.com/v0/b/<bucket>/o/
• Evidence: Anonymous list returned every uploaded file. Filenames followed <user_email>_<timestamp>.png so PII was leaking even from the listing.
• Impact: Full file enumeration, PII through filenames.
• Fix: Update Firestore Storage Rules to require auth on read and to scope writes by request.auth.uid. Use unguessable filenames.

Finding F - Mass assignment on a Windsurf + Express app

• Endpoint: PATCH /api/profile
• Evidence: Handler did User.update(req.body) without field whitelist. POST with {"role": "admin"} upgraded the requester.
• Impact: Any user becomes admin.
• Fix: Whitelist updatable fields. Treat role, id, email_verified as system-managed.

Finding G - Hallucinated dependency in a Claude Code project

• Endpoint: N/A (build-time)
• Evidence: package.json contained a dependency name that did not exist on npm. The build worked locally because the resolution failed silently and the import was unused. After someone published a package with the same name, every fresh install would have pulled attacker code.
• Impact: Future supply chain compromise.
• Fix: Run Package Hallucination Scanner on every commit. Pin versions. Enable npm audit signatures.

Finding H - Source map exposed on a Lovable production build

• Endpoint: https://app.example.com/assets/index-abc.js.map
• Evidence: Source map deployed to production. Full unminified source recoverable, including comments referencing internal API design and a placeholder // TODO: replace this hardcoded JWT secret.
• Impact: Trivial reverse engineering plus secret leak through committed comments.
• Fix: Disable source map generation for production builds, or upload to an authenticated error-tracking service rather than the public CDN.

Kill chain on a vibe-coded app

Anonymized but representative.

Step 1 - Recon on a Lovable app. Bundle inspected. Supabase URL extracted. PostgREST schema fetched at /rest/v1/. 23 tables discovered.

Step 2 - RLS sweep. Anonymous SELECT against each table. 21 return empty. Two - feedback_messages and support_replies - return rows.

Step 3 - PII triage. feedback_messages contains user email, message body, and user IP. support_replies contains the admin’s response, which sometimes includes account-recovery links.

Step 4 - Account recovery link extraction. The agent searches support_replies for URL patterns matching the app’s reset link template. Two valid, unexpired reset URLs are recovered.

Step 5 - Account takeover. The reset URL works (no IP binding, no second factor). The agent does not actually take over the account but reports the chain as a high-severity finding.

Step 6 - Lateral. With the (theoretical) takeover, the agent identifies the privilege escalation possibilities - admin role on profiles, organization owner on org_members - and includes them in the report as the next steps an attacker would take.

The chain is reported as one root cause (RLS missing on two tables) with three downstream impacts. The fix is surgical. The rescan would close the chain.

When you should NOT run a vibe pentest

• You haven’t shipped yet. Run Vibe Code Scanner on the staging URL first; the pentest is for deployed apps.
• You don’t own the target. No matter how curious you are about another team’s Lovable app, do not pentest it without written authorization. The AI agent will happily comply, but the law will not.
• The app is not web-shaped. CLI tools, native apps, on-device models - different methodology.
• You need a deep one-bug investigation. Vibe pentesting is broad coverage. For deep work on a specific class, hire a human researcher.
• You’re testing safety/alignment of an LLM, not security of an app. Different category - see AI red teaming discussion of LLM-specific testing.

Methodology: reconnaissance phase

Recon for vibe-coded apps is heavier on artifact analysis than classical network scans.

Browser and bundle

1. Load the root URL and major routes in a headless browser with a clean profile.
2. Capture all script URLs; download and parse for:
   • Supabase/Firebase project references
   • JWT-shaped strings (eyJ...)
   • sk_live_, sk_test_, sk-ant-, AKIA, private key PEMs
   • Feature flags and admin email lists
3. Note third-party script origins (analytics, payment.js, chat widgets) - supply chain for XSS.
4. Check for source maps (*.js.map) and .git exposure.

API surface mapping

1. From network traffic, build a method × path table.
2. From PostgREST OpenAPI (/rest/v1/) when Supabase is present, list tables and RPC names.
3. From JS route tables (React Router), list client paths that imply admin or settings.
4. Guess only after passive mapping - AI apps still use predictable names (/api/admin, /functions/v1/stripe-webhook).

Fingerprint → playbook selection

Wrong playbook wastes probes; right playbook finds criticals in the first minute.

Methodology: authorization testing

Identity matrix

Minimum identities:

• Anon (no cookie, no Authorization)
• User A (standard role)
• User B (peer role, other tenant if SaaS)
• Admin / owner if the product has one

Optional: revoked user, email-unverified user, free vs paid plan users.

Object matrix

For each resource type (invoice, message, file, org):

1. Create as A; note id.
2. Read/update/delete as B and as anon.
3. List/search as B with filters that should not reveal A’s objects.
4. Attempt mass assignment on update (role, plan, user_id, tenant_id).

Pass/fail

Prefer 404 over 403 for cross-tenant misses to reduce id oracle usefulness - note either as design commentary, but data return is the severity driver.

Methodology: storage and files

1. Discover bucket names from JS or network (/storage/v1/object/public/...).
2. Attempt unauthenticated list and download.
3. Upload as A; download as B with direct URL.
4. Try path traversal-style keys (../, overlong paths) where applicable.
5. Check content-type enforcement (HTML/SVG as “images”).

Public marketing assets are fine; user invoices in a public bucket are not.

Methodology: webhooks and payments

1. Find webhook routes (stripe, resend, github, clerk).
2. POST unsigned JSON that would grant plan or mark invoice paid.
3. Replay a captured valid webhook if staging allows.
4. Flip client-side amounts only as a secondary check - server price is the real control.

Any state change without signature verification is High/Critical depending on money impact.

Scenario library (expanded)

Scenario 1 - “Ship for demo day”

Setup: RLS disabled for investor demo, never re-enabled.
Pentest moves: anon select on all tables; screenshot row counts; severity Critical.
Fix: enable RLS; seed demo accounts instead of open data.

Scenario 2 - “Add AI descriptions”

Setup: Feature prompt adds OpenAI key in VITE_.
Pentest moves: bundle grep; key validation against provider; cost abuse note.
Fix: server proxy + budget (API abuse).

Scenario 3 - “Teams in one afternoon”

Setup: org_id column added; policies still auth.uid() = user_id only or trust client org_id.
Pentest moves: user in org B sets org_id to A on insert; reads A’s rows.
Fix: membership-checked policies; see multi-tenant SaaS pentest guide.

Scenario 4 - “Stripe quickstart”

Setup: Webhook from docs without constructEvent.
Pentest moves: forge checkout.session.completed.
Fix: signature + idempotency.

Scenario 5 - “Admin for support”

Setup: ADMIN_EMAILS in frontend.
Pentest moves: call /api/admin/* as non-admin.
Fix: server role checks + audit log.

Scenario 6 - “Public roadmap board”

Setup: Intentionally public table; accidental PII columns.
Pentest moves: select *; check columns.
Fix: view with column allowlist; separate public table.

Scenario 7 - “Preview equals prod DB”

Setup: Vercel preview with production Supabase service role.
Pentest moves: find preview URL via common patterns; use leaked service role if present.
Fix: branched DBs; secret separation.

Scenario 8 - “Hallucinated helper package”

Setup: package.json includes non-existent name now parked by attacker.
Pentest moves: static manifest check (not only runtime).
Fix: package hallucination scanner; pin and verify.

Evidence standards for vibe pentest reports

Each finding should include:

1. Title with boundary (anon/user/admin) and asset.
2. Severity using a written rubric (Critical = full PII dump or auth bypass to admin).
3. Evidence - request/response excerpts, redacting unrelated secrets in customer copies when needed but keeping enough to repro.
4. Impact in business language (which users, what data).
5. Root cause (missing RLS, no ownership check, etc.).
6. Fix prompt aimed at the generator tool.
7. Rescan criteria - what observation closes the ticket.

Avoid “might be vulnerable” language when you have a 200 with another user’s email.

Integrating with human pentests and bounties

Recommended stack:

Every deploy: vibe pentest / scanner (floor)
Quarterly or pre-enterprise: human pentest (depth)
Ongoing: bug bounty (creativity)

Hand humans the vibe report so they do not waste days on missing RLS. Hand bounty hunters a clear scope and known fixed issues. Vibe pentest is the hygiene layer; it is not a trophy hunt.

Metrics for continuous vibe pentesting

Agencies: track per-client scorecards. Founders: track before/after each major prompt session.

Limitations and honesty bar

Vibe pentesting will under-index on:

• Complex business logic fraud (insurance claim workflows, multi-step approvals)
• Race conditions that need careful timing
• Novel cryptography bugs
• Insider threats with legitimate high roles
• Mobile certificate pinning bypass (out of web scope)

It will over-index on exactly what sinks vibe-coded startups: open data planes, leaked keys, IDOR, and copy-paste webhooks. Match the tool to the risk.

AuthN vs AuthZ: the confusion AI spreads

Many generators “add auth” by:

1. Supabase magic link works.
2. React route hides /dashboard when session is null.

Vibe pentest explicitly separates:

• Authentication - is the identity real?
• Authorization - may this identity touch this object?

Probes always include authenticated-but-unauthorized users. If your only negative test is “logged out user cannot see UI,” you are not testing security.

Kill chain practice for teams

Run a quarterly authorized purple-team day:

1. Red: only public URL and this methodology.
2. Blue: only logs and alerts they already have.
3. Score: did blue notice the anon select=* spike?

If blue is blind, invest in logging before more unit tests. Kill chains in the findings section above are templates for that exercise.

Fix prompts you can paste into the AI tool that built the app

Generic vibe-pentest fix prompt

The vibe pentest report below identifies a security issue in this app.
Apply the fix described, and only that fix. Do not refactor unrelated code.
Add a regression test that proves the issue is closed. After the patch
ships, the rescan should not re-emit this finding.

<paste finding>

Lovable-specific RLS fix prompt

Enable Row Level Security on the table `<table>` and write four policies that
gate SELECT, INSERT, UPDATE, and DELETE on `auth.uid() = user_id`. Generate
the SQL migration. Do not break any existing service-role usage.

v0 / Next.js server action lockdown prompt

The server action at `<path>` is callable without authentication. Add an
auth check at the top of the action: read the session, return a 401 (or
redirect) if missing. Then add an authorization check: confirm the session
user owns the resource the action is touching. Add a regression test.

Cursor / Claude Code generic fix prompt

The endpoint `<METHOD> <route>` is vulnerable to <vuln class>. Apply the
fix below. Do not modify other endpoints in this PR.

Evidence: <copy-paste the request/response from the report>
Root cause: <copy-paste from the report>
Fix: <copy-paste the recommended fix>

Add a regression test in the existing test suite that asserts the
vulnerability is closed.

Bolt / Replit generic prompt

Production deploy of this app has the security issue described below.
Patch in place. Do not introduce new dependencies. Re-run the deploy when
the patch is in.

<finding>

Sample timeline: first vibe pentest on a new app

Minute 0–1: Fingerprint generator; extract project URL and anon key; list scripts.
Minute 1–3: PostgREST/OpenAPI or route map; anon probes on top tables; Storage list.
Minute 3–8: Create two users if signup open; BOLA matrix on primary resources.
Minute 8–12: Functions/webhooks/unsigned posts; bundle secret grep.
Minute 12–15: Draft findings with evidence; generate fix prompts; schedule rescan.

Humans extend past minute 15 into business logic. The first quarter hour should already catch launch-blockers.

Collaboration with developers who only use chat IDEs

Many vibe coders never open a terminal. Delivery format matters:

• Findings as copy-paste prompts, not only PDF jargon
• Severity in product language (“anyone can download all invoices”)
• Rescan link in the same email as the fix
• Avoid shaming the tool - shame the missing test

Adoption beats perfect taxonomy.

Appendix: quick command cheatsheet (authorized targets only)

# Bundle secrets (rough)
curl -sL "$URL" | grep -oE 'eyJ[a-zA-Z0-9_-]+\.[a-zA-Z0-9_-]+\.[a-zA-Z0-9_-]+' | head

# Supabase REST probe
curl -s "$SUPA/rest/v1/profiles?select=*&limit=1" \
  -H "apikey: $ANON" -H "Authorization: Bearer $ANON"

# Cross-user (replace tokens/ids)
curl -s "$API/invoices/$ID_A" -H "Authorization: Bearer $TOKEN_B"

Automate these inside the agent; keep them for manual confirmation when disputing a finding.

Operational verification for ai-pentest/vibe-pentesting.md (pass 1)

For this page’s subject matter, treat authentication, authorization, secrets, webhooks, and data-plane rules as ship gates. After every AI-assisted change:

1. Dual-user tests (owner vs stranger) on every new resource ID
2. Anonymous probes of new routes and storage paths
3. Bundle/token leak check for public env prefixes and service roles
4. Live URL scan on preview and production
5. Webhook signature failure tests where payments or entitlements are involved

Encode proofs in CI when possible. Temporary exceptions need tickets with expiry dates. Agent shortcuts that open policies, public secret prefixes, or skip signatures are release blockers until closed.

# Proof sketch tailored to ai-pentest/vibe-pentesting.md
curl -s -o /dev/null -w '%{http_code}\n' "$URL/api/protected"
curl -s -H "Authorization: Bearer $TOKEN_B" "$URL/api/resources/$ID_A" -w '\n%{http_code}\n'

Regression signals specific to this surface

• Permission-denied metrics drop after a rules or policy deploy without a matching product change
• 401/403 spikes on admin or object routes without a launch
• New packages merged without registry age and maintainer checks
• Preview environments inheriting production secrets or service roles
• Unsigned webhook payloads accepted in staging clones of production

Ownership

Name a human owner for this control surface. Keep CODEOWNERS on auth, payments, policy files, and CI workflows. Rehearse key rotation for the primary secret class this stack uses. Record the last green dual-user pass date in the release ticket.

Operational verification for ai-pentest/vibe-pentesting.md (pass 2)

For this page’s subject matter, treat authentication, authorization, secrets, webhooks, and data-plane rules as ship gates. After every AI-assisted change:

1. Dual-user tests (owner vs stranger) on every new resource ID
2. Anonymous probes of new routes and storage paths
3. Bundle/token leak check for public env prefixes and service roles
4. Live URL scan on preview and production
5. Webhook signature failure tests where payments or entitlements are involved

Encode proofs in CI when possible. Temporary exceptions need tickets with expiry dates. Agent shortcuts that open policies, public secret prefixes, or skip signatures are release blockers until closed.

# Proof sketch tailored to ai-pentest/vibe-pentesting.md
curl -s -o /dev/null -w '%{http_code}\n' "$URL/api/protected"
curl -s -H "Authorization: Bearer $TOKEN_B" "$URL/api/resources/$ID_A" -w '\n%{http_code}\n'

Regression signals specific to this surface

• Permission-denied metrics drop after a rules or policy deploy without a matching product change
• 401/403 spikes on admin or object routes without a launch
• New packages merged without registry age and maintainer checks
• Preview environments inheriting production secrets or service roles
• Unsigned webhook payloads accepted in staging clones of production

Ownership

Name a human owner for this control surface. Keep CODEOWNERS on auth, payments, policy files, and CI workflows. Rehearse key rotation for the primary secret class this stack uses. Record the last green dual-user pass date in the release ticket.

Operational verification for ai-pentest/vibe-pentesting.md (pass 3)

For this page’s subject matter, treat authentication, authorization, secrets, webhooks, and data-plane rules as ship gates. After every AI-assisted change:

1. Dual-user tests (owner vs stranger) on every new resource ID
2. Anonymous probes of new routes and storage paths
3. Bundle/token leak check for public env prefixes and service roles
4. Live URL scan on preview and production
5. Webhook signature failure tests where payments or entitlements are involved

Encode proofs in CI when possible. Temporary exceptions need tickets with expiry dates. Agent shortcuts that open policies, public secret prefixes, or skip signatures are release blockers until closed.

# Proof sketch tailored to ai-pentest/vibe-pentesting.md
curl -s -o /dev/null -w '%{http_code}\n' "$URL/api/protected"
curl -s -H "Authorization: Bearer $TOKEN_B" "$URL/api/resources/$ID_A" -w '\n%{http_code}\n'

Regression signals specific to this surface

• Permission-denied metrics drop after a rules or policy deploy without a matching product change
• 401/403 spikes on admin or object routes without a launch
• New packages merged without registry age and maintainer checks
• Preview environments inheriting production secrets or service roles
• Unsigned webhook payloads accepted in staging clones of production

Ownership

Name a human owner for this control surface. Keep CODEOWNERS on auth, payments, policy files, and CI workflows. Rehearse key rotation for the primary secret class this stack uses. Record the last green dual-user pass date in the release ticket.

Operational verification for ai-pentest/vibe-pentesting.md (pass 4)

For this page’s subject matter, treat authentication, authorization, secrets, webhooks, and data-plane rules as ship gates. After every AI-assisted change:

1. Dual-user tests (owner vs stranger) on every new resource ID
2. Anonymous probes of new routes and storage paths
3. Bundle/token leak check for public env prefixes and service roles
4. Live URL scan on preview and production
5. Webhook signature failure tests where payments or entitlements are involved

Encode proofs in CI when possible. Temporary exceptions need tickets with expiry dates. Agent shortcuts that open policies, public secret prefixes, or skip signatures are release blockers until closed.

# Proof sketch tailored to ai-pentest/vibe-pentesting.md
curl -s -o /dev/null -w '%{http_code}\n' "$URL/api/protected"
curl -s -H "Authorization: Bearer $TOKEN_B" "$URL/api/resources/$ID_A" -w '\n%{http_code}\n'

Regression signals specific to this surface

• Permission-denied metrics drop after a rules or policy deploy without a matching product change
• 401/403 spikes on admin or object routes without a launch
• New packages merged without registry age and maintainer checks
• Preview environments inheriting production secrets or service roles
• Unsigned webhook payloads accepted in staging clones of production

Ownership

Name a human owner for this control surface. Keep CODEOWNERS on auth, payments, policy files, and CI workflows. Rehearse key rotation for the primary secret class this stack uses. Record the last green dual-user pass date in the release ticket.

Operational verification for ai-pentest/vibe-pentesting.md (pass 5)

For this page’s subject matter, treat authentication, authorization, secrets, webhooks, and data-plane rules as ship gates. After every AI-assisted change:

1. Dual-user tests (owner vs stranger) on every new resource ID
2. Anonymous probes of new routes and storage paths
3. Bundle/token leak check for public env prefixes and service roles
4. Live URL scan on preview and production
5. Webhook signature failure tests where payments or entitlements are involved

Encode proofs in CI when possible. Temporary exceptions need tickets with expiry dates. Agent shortcuts that open policies, public secret prefixes, or skip signatures are release blockers until closed.

# Proof sketch tailored to ai-pentest/vibe-pentesting.md
curl -s -o /dev/null -w '%{http_code}\n' "$URL/api/protected"
curl -s -H "Authorization: Bearer $TOKEN_B" "$URL/api/resources/$ID_A" -w '\n%{http_code}\n'

Regression signals specific to this surface

• Permission-denied metrics drop after a rules or policy deploy without a matching product change
• 401/403 spikes on admin or object routes without a launch
• New packages merged without registry age and maintainer checks
• Preview environments inheriting production secrets or service roles
• Unsigned webhook payloads accepted in staging clones of production

Ownership

Name a human owner for this control surface. Keep CODEOWNERS on auth, payments, policy files, and CI workflows. Rehearse key rotation for the primary secret class this stack uses. Record the last green dual-user pass date in the release ticket.

Operational verification for ai-pentest/vibe-pentesting.md (pass 6)

For this page’s subject matter, treat authentication, authorization, secrets, webhooks, and data-plane rules as ship gates. After every AI-assisted change:

1. Dual-user tests (owner vs stranger) on every new resource ID
2. Anonymous probes of new routes and storage paths
3. Bundle/token leak check for public env prefixes and service roles
4. Live URL scan on preview and production
5. Webhook signature failure tests where payments or entitlements are involved

Encode proofs in CI when possible. Temporary exceptions need tickets with expiry dates. Agent shortcuts that open policies, public secret prefixes, or skip signatures are release blockers until closed.

# Proof sketch tailored to ai-pentest/vibe-pentesting.md
curl -s -o /dev/null -w '%{http_code}\n' "$URL/api/protected"
curl -s -H "Authorization: Bearer $TOKEN_B" "$URL/api/resources/$ID_A" -w '\n%{http_code}\n'

Regression signals specific to this surface

• Permission-denied metrics drop after a rules or policy deploy without a matching product change
• 401/403 spikes on admin or object routes without a launch
• New packages merged without registry age and maintainer checks
• Preview environments inheriting production secrets or service roles
• Unsigned webhook payloads accepted in staging clones of production

Ownership

Name a human owner for this control surface. Keep CODEOWNERS on auth, payments, policy files, and CI workflows. Rehearse key rotation for the primary secret class this stack uses. Record the last green dual-user pass date in the release ticket.

Operational verification for ai-pentest/vibe-pentesting.md (pass 7)

For this page’s subject matter, treat authentication, authorization, secrets, webhooks, and data-plane rules as ship gates. After every AI-assisted change:

1. Dual-user tests (owner vs stranger) on every new resource ID
2. Anonymous probes of new routes and storage paths
3. Bundle/token leak check for public env prefixes and service roles
4. Live URL scan on preview and production
5. Webhook signature failure tests where payments or entitlements are involved

Encode proofs in CI when possible. Temporary exceptions need tickets with expiry dates. Agent shortcuts that open policies, public secret prefixes, or skip signatures are release blockers until closed.

# Proof sketch tailored to ai-pentest/vibe-pentesting.md
curl -s -o /dev/null -w '%{http_code}\n' "$URL/api/protected"
curl -s -H "Authorization: Bearer $TOKEN_B" "$URL/api/resources/$ID_A" -w '\n%{http_code}\n'

Regression signals specific to this surface

• Permission-denied metrics drop after a rules or policy deploy without a matching product change
• 401/403 spikes on admin or object routes without a launch
• New packages merged without registry age and maintainer checks
• Preview environments inheriting production secrets or service roles
• Unsigned webhook payloads accepted in staging clones of production

Ownership

Name a human owner for this control surface. Keep CODEOWNERS on auth, payments, policy files, and CI workflows. Rehearse key rotation for the primary secret class this stack uses. Record the last green dual-user pass date in the release ticket.

Operational verification for ai-pentest/vibe-pentesting.md (pass 8)

For this page’s subject matter, treat authentication, authorization, secrets, webhooks, and data-plane rules as ship gates. After every AI-assisted change:

1. Dual-user tests (owner vs stranger) on every new resource ID
2. Anonymous probes of new routes and storage paths
3. Bundle/token leak check for public env prefixes and service roles
4. Live URL scan on preview and production
5. Webhook signature failure tests where payments or entitlements are involved

Encode proofs in CI when possible. Temporary exceptions need tickets with expiry dates. Agent shortcuts that open policies, public secret prefixes, or skip signatures are release blockers until closed.

# Proof sketch tailored to ai-pentest/vibe-pentesting.md
curl -s -o /dev/null -w '%{http_code}\n' "$URL/api/protected"
curl -s -H "Authorization: Bearer $TOKEN_B" "$URL/api/resources/$ID_A" -w '\n%{http_code}\n'

Regression signals specific to this surface

• Permission-denied metrics drop after a rules or policy deploy without a matching product change
• 401/403 spikes on admin or object routes without a launch
• New packages merged without registry age and maintainer checks
• Preview environments inheriting production secrets or service roles
• Unsigned webhook payloads accepted in staging clones of production

Ownership

Name a human owner for this control surface. Keep CODEOWNERS on auth, payments, policy files, and CI workflows. Rehearse key rotation for the primary secret class this stack uses. Record the last green dual-user pass date in the release ticket.

Operational verification for ai-pentest/vibe-pentesting.md (pass 9)

For this page’s subject matter, treat authentication, authorization, secrets, webhooks, and data-plane rules as ship gates. After every AI-assisted change:

1. Dual-user tests (owner vs stranger) on every new resource ID
2. Anonymous probes of new routes and storage paths
3. Bundle/token leak check for public env prefixes and service roles
4. Live URL scan on preview and production
5. Webhook signature failure tests where payments or entitlements are involved

Encode proofs in CI when possible. Temporary exceptions need tickets with expiry dates. Agent shortcuts that open policies, public secret prefixes, or skip signatures are release blockers until closed.

# Proof sketch tailored to ai-pentest/vibe-pentesting.md
curl -s -o /dev/null -w '%{http_code}\n' "$URL/api/protected"
curl -s -H "Authorization: Bearer $TOKEN_B" "$URL/api/resources/$ID_A" -w '\n%{http_code}\n'

Regression signals specific to this surface

• Permission-denied metrics drop after a rules or policy deploy without a matching product change
• 401/403 spikes on admin or object routes without a launch
• New packages merged without registry age and maintainer checks
• Preview environments inheriting production secrets or service roles
• Unsigned webhook payloads accepted in staging clones of production

Ownership

Name a human owner for this control surface. Keep CODEOWNERS on auth, payments, policy files, and CI workflows. Rehearse key rotation for the primary secret class this stack uses. Record the last green dual-user pass date in the release ticket.

Operational verification for ai-pentest/vibe-pentesting.md (pass 10)

For this page’s subject matter, treat authentication, authorization, secrets, webhooks, and data-plane rules as ship gates. After every AI-assisted change:

1. Dual-user tests (owner vs stranger) on every new resource ID
2. Anonymous probes of new routes and storage paths
3. Bundle/token leak check for public env prefixes and service roles
4. Live URL scan on preview and production
5. Webhook signature failure tests where payments or entitlements are involved

Encode proofs in CI when possible. Temporary exceptions need tickets with expiry dates. Agent shortcuts that open policies, public secret prefixes, or skip signatures are release blockers until closed.

# Proof sketch tailored to ai-pentest/vibe-pentesting.md
curl -s -o /dev/null -w '%{http_code}\n' "$URL/api/protected"
curl -s -H "Authorization: Bearer $TOKEN_B" "$URL/api/resources/$ID_A" -w '\n%{http_code}\n'

Regression signals specific to this surface

• Permission-denied metrics drop after a rules or policy deploy without a matching product change
• 401/403 spikes on admin or object routes without a launch
• New packages merged without registry age and maintainer checks
• Preview environments inheriting production secrets or service roles
• Unsigned webhook payloads accepted in staging clones of production

Ownership

Name a human owner for this control surface. Keep CODEOWNERS on auth, payments, policy files, and CI workflows. Rehearse key rotation for the primary secret class this stack uses. Record the last green dual-user pass date in the release ticket.

Tool-specific vibe pentests

• Lovable Pentesting - Lovable-specific methodology and fixes
• Lovable Safety Guide - Lovable-specific failure modes
• Cursor Safety Guide - Cursor-specific failure modes
• Bolt Safety Guide - Bolt-specific failure modes
• v0 Safety Guide - v0-specific failure modes
• Replit Safety Guide - Replit-specific failure modes
• Claude Code Safety Guide - Claude Code-specific failure modes
• Windsurf Safety Guide - Windsurf-specific failure modes
• GitHub Copilot Safety Guide - Copilot-specific failure modes
• Devin Safety Guide - Devin-specific failure modes
• Supabase Safety Guide - Supabase-as-a-backend risks
• Firebase Safety Guide - Firebase-as-a-backend risks
• Cursor vs Claude Code Security - code-assistant security comparison
• Lovable Guides - Lovable-specific build guides
• Cursor Guides - Cursor-specific build guides
• Lovable Checklists - Lovable pre-launch checklist
• AI Pentesting Explained - what AI pentesting means and how it works
• AI Pentest vs Traditional - deeper comparison
• AI Pentest for Web Applications - broader web-app pentest scope
• AI Pentest for APIs - API-specific scope
• Continuous Penetration Testing - every-deploy cadence
• PTaaS - subscription pentest model
• AI Coding Tool Security Hub - vulnerability taxonomy across every AI coding tool
• Vibe-Coding Vulnerabilities - full 14-pattern taxonomy
• Vibe Code Scanner - run the free scanner
• Token Leak Checker - focused scan for exposed keys
• Supabase RLS Checker - Supabase-specific RLS audit
• Firebase Scanner - Firestore Rules audit
• Security Headers Checker - CSP, HSTS, CORS audit
• Package Hallucination Scanner - find AI-invented dependencies
• Best Security Scanner for AI Apps - category comparison
• VibeEval vs Burp Suite - AI agent vs manual pentest tool
• VibeEval vs OWASP ZAP - AI agent vs DAST scanner
• VibeEval vs Snyk - runtime AI pentest vs SAST + SCA
• Integration Layer Is the Real Security Gap - why integration code is the worst-tested layer
• OWASP Top 10 for AI Code - canonical failure modes

Engagement scoping for vibe-coded targets

Inventory generators used, BaaS providers, hosting, and whether source is available. Prioritize anonymous data plane tests first - they dominate real outcomes - then authenticated BOLA, then integrations.

Deliverables that help builders

Findings should include: severity, evidence request/response, reproduction steps, fix prompt for Cursor/Lovable, and retest result. Screenshots without replay steps waste the client’s engineering time.