Pentest Checklist for Vibe-Coded SaaS Apps (2026)

Vibe-coded SaaS apps (built with Cursor, Lovable, Bolt.new, v0 by Vercel, Replit Agent) ship faster than hand-written code but inherit predictable security gaps. The top failure patterns across tools: Supabase Row Level Security disabled or misconfigured, AI provider API keys leaked in client bundles, Stripe webhooks without signature verification, authentication middleware skipped on catch-all routes, and unrate-limited LLM endpoints draining billing within hours of launch. This post is a per-tool pentest checklist for vibe-coded SaaS, written for founders launching pre-Series-A and for CTOs heading into enterprise customer onboarding or investor diligence.

Key findings

• Supabase RLS misconfiguration is the #1 gap in vibe-coded apps we pentest. Affects roughly 70% of apps built with Cursor, Lovable, and Bolt.new based on patterns we see. Tables get scaffolded without RLS enabled, or policies use auth.uid() while leaving anon-role SELECT open.
• AI provider API key exposure (OpenAI, Anthropic) in client code is the #2 gap. The LLM scaffolds endpoints that pass the key directly to the browser. First hostile actor abuses the endpoint and the OpenAI billing burns within hours.
• Stripe webhook signature missing is the #3 gap. Tools scaffold the webhook handler endpoint but skip the signature verification step. Any attacker can post fake payment_intent.succeeded events.
• Authentication middleware coverage gaps are predictable. Tools add auth checks to listed routes but miss catch-all routes, dynamic segments, and API routes added later. Pentest must test EVERY route, not a sample.
• Outdated dependencies with known CVEs ship because the LLM training cutoff lags the library release cadence. npm audit catches most; pentest catches the ones with no public advisory yet.
• Pre-launch pentest scope for a vibe-coded SaaS focuses on auth, authorization, payments, secrets, rate limiting, dependencies, and prompt injection (if LLM features exist). Skip mobile, deep infra, and physical for v1.
• Pricing benchmark: Cybersecify Startup Pentest INR 74,999 (1 scope, 7 days, 6 founder-led consulting hours, 1 free retest). Growth Pentest INR 1,79,999 (2 scopes, 10 days, 12 founder-led consulting hours, SOC 2 + ISO 27001 evidence, real-world attack simulation, 1 free retest).

Cybersecify is a founder-led penetration testing firm based in Bengaluru, India, serving AI-first and API-first SaaS startups. We pentest apps built with Cursor, Lovable, Bolt.new, v0 by Vercel, Replit Agent, and hand-written stacks. The patterns below come from real pentest engagements on vibe-coded SaaS over the last 12 months. For a sample of the deliverable, see our pentest report sample.

What “vibe-coded” means in 2026

Vibe coding is the term founders started using in late 2025 for AI-assisted development where the human describes the desired outcome and the LLM scaffolds the code. The tools doing this in 2026:

• Cursor. AI-first code editor. Most popular vibe-coding tool for engineering-leaning founders. Generates code in your editor; you commit.
• Lovable. Browser-based full-stack app builder. Produces React + Supabase apps from natural language prompts. Strong with non-engineer founders.
• Bolt.new. Browser-based full-stack builder by StackBlitz. Generates Vite + React or Next.js + Supabase apps.
• v0 by Vercel. UI-first generator with full-stack capability. Strongest on Tailwind + shadcn/ui component patterns.
• Replit Agent. Replit’s autonomous coding agent. Builds end-to-end inside the Replit environment.

Across all five, the runtime stack converges on a small set of choices: React or Next.js for frontend, Supabase or Firebase for backend-as-a-service, Stripe for payments, Clerk or Auth0 or Supabase Auth for identity, OpenAI or Anthropic for AI features, Vercel or Cloudflare or Replit for hosting. This convergence is what makes a per-tool pentest checklist tractable.

Per-tool pentest checklist

Cursor-built SaaS apps

Cursor sits inside your editor so the apps it produces look like apps you wrote, which is what makes them tricky to pentest from the developer’s perspective. The pentester does not benefit from this familiarity, which is the point.

What to test specifically:

1. Supabase RLS coverage. Cursor often scaffolds tables and triggers without enabling Row Level Security. Run SELECT relname, relrowsecurity FROM pg_class WHERE relkind = 'r' AND relnamespace = 'public'::regnamespace and confirm relrowsecurity = true on every table holding user data. Then validate the policies themselves auth.uid() = user_id is correct; auth.uid() IS NOT NULL is too loose.
2. Service-role key in client code. SUPABASE_SERVICE_ROLE_KEY should NEVER appear in client-side code. Grep the production bundle. If it appears, every customer can bypass RLS.
3. Stripe webhook signature verification. The handler should call stripe.webhooks.constructEvent(body, signature, secret) and reject unsigned requests. Cursor sometimes scaffolds the endpoint without this step. Send a fake payment_intent.succeeded event from your testing tool; if the handler accepts it, signature is missing.
4. Authentication middleware on EVERY route. In Next.js, the middleware.ts file or per-route getServerSession() checks should cover every protected route. Pentest enumerates routes from the route manifest, not from documentation.
5. AI API key exposure. Grep the client bundle for sk-, sk-ant-, OPENAI_API_KEY, ANTHROPIC_API_KEY. If any match, the key is exposed.
6. CORS configuration. Access-Control-Allow-Origin: * should not appear in production. Tighten to specific origins.
7. Rate limiting on AI endpoints. Send 100 requests per second to your /api/chat or /api/generate endpoint. If the OpenAI bill notification arrives before the 429 response, rate limiting is missing.
8. Environment variable exposure. In Next.js, only variables prefixed NEXT_PUBLIC_ should be exposed to the browser. Audit the client bundle for any backend-only variables that leaked through accidental prefixing.

Lovable-built apps

Lovable produces React + Supabase apps from natural language. The Supabase backend is the centre of the security model.

What to test specifically:

1. RLS enablement on EVERY table. Same query as Cursor. Lovable scaffolds tables sensibly but the RLS step is often left as TODO during iteration.
2. Policy correctness. Lovable-generated policies frequently use the wrong column for ownership comparison (e.g., comparing auth.uid() to id instead of user_id). Test ownership boundaries with a second authenticated session attempting to read or modify the first user’s resources.
3. Anon-role SELECT exposure. Policies that grant SELECT to the anon role effectively make the data public. Anyone with the published anon key (it is in the client bundle by design) can read.
4. Storage bucket policies. Lovable apps frequently use Supabase Storage. Buckets default to private but uploaded objects can be made public by URL. Test bucket-level policies and signed URL expiration.
5. Realtime subscription leakage. Supabase Realtime broadcasts row changes to subscribed clients. RLS applies to Realtime BUT only when explicitly configured. Test by subscribing as an unauthenticated client and watching for events.
6. Stripe integration. Lovable scaffolds Stripe Checkout flows. Verify the webhook endpoint validates signatures and the success-page server-side validates the session ID (not just trusts the URL parameter).
7. AI feature secret handling. Lovable-generated AI features should use a server-side route (Supabase Edge Function) that holds the OpenAI key, not pass it client-side.
8. Authentication flow integrity. Default Lovable auth uses Supabase Auth. Test password reset (does it expire?), email change (is verification required?), session invalidation (does logout invalidate other sessions?).

Bolt.new-built apps

Bolt.new produces Vite + React or Next.js apps with a backend choice. The pentest scope expands or narrows based on the stack the LLM picked.

What to test specifically:

1. API route authentication consistency. Bolt-generated apps often have a mix of authenticated and unauthenticated API routes. Enumerate every route and test auth on each. Catch-all routes ([...slug].ts) are the common miss.
2. Backend choice security model. If Supabase, same RLS checks as Lovable. If Firebase, Firebase Security Rules instead. If custom Express backend, full OWASP API Top 10 surface.
3. Vite environment variable exposure. Vite exposes VITE_ prefixed variables to the client. Audit for any backend secret accidentally prefixed VITE_.
4. Bundled secrets. Build the production bundle and grep for known secret patterns (sk-, AKIA, eyJ JWT prefix, https://hooks.slack.com/, etc).
5. Dependency CVE posture. npm audit --production or bun audit. Address criticals and highs.
6. Authentication library posture. Bolt frequently scaffolds Clerk, Auth0, or Supabase Auth. For Clerk: verify webhook signature on user.created events. For Auth0: verify ID token signature server-side. For Supabase Auth: verify JWT signature with the project secret.
7. CORS posture. Default Vite dev config allows all origins. Production server should tighten. Audit the deployed nginx, Vercel, Cloudflare, or backend framework config.

v0 by Vercel-built apps

v0 leans toward UI generation but produces full-stack code when prompted. Deployment is usually Vercel.

What to test specifically:

1. Server Actions authentication. v0 frequently uses Next.js Server Actions for backend logic. Server Actions are POST endpoints; they need explicit authentication and authorization checks at the function boundary, not just the page boundary.
2. Server Component data exposure. Data fetched in a Server Component renders into the page HTML. Audit for sensitive data accidentally fetched and rendered (e.g., admin-only data in a layout component).
3. Vercel environment variable scope. Vercel supports preview, production, and development environment variable scopes. Verify the preview environment is not using production credentials.
4. shadcn/ui pattern reuse. v0 reuses shadcn component patterns. The patterns themselves are secure but reuse without context can lead to e.g. form components that trust client-side validation only.
5. Edge runtime constraints. v0 sometimes generates code targeting Vercel Edge runtime. Edge runtime cannot use Node-only APIs (crypto, fs), which means some security primitives fall back to Web Crypto. Verify the cryptographic implementation if security-critical (token signing, password hashing).
6. Authentication library defaults. v0 generates with Clerk or NextAuth. Verify session handling, CSRF token presence on state-changing endpoints, and logout invalidation.

Replit Agent-built apps

Replit Agent builds end-to-end inside Replit. The deployment target is Replit’s hosting.

What to test specifically:

1. Replit Secrets handling. Secrets entered in the Replit Secrets pane are environment variables. Verify no secret has been hardcoded in source instead.
2. Replit Database vs Postgres choice. If using Replit’s built-in DB, the auth model is the Repl owner’s identity, which means cross-tenant isolation requires explicit code. If Postgres (Neon, Supabase), apply the stack-specific RLS checks.
3. Public Repl exposure. Repls default to public. If the production app is running from a public Repl, source code is browsable. Move to a private Repl for production.
4. Authentication flow. Replit Agent generates auth flows with Replit Auth, Clerk, or custom JWT. Validate signature verification, refresh token handling, and session invalidation.
5. Webhook endpoint coverage. Stripe, Razorpay, or other payment webhooks need signature verification. Test by sending a fake event.
6. Resource limits and abuse. Replit Always-On Repls have resource limits. Test DOS resilience and rate limiting.

Decision matrix per stage

Stage / Trigger	Recommended pentest scope	Cybersecify plan
Pre-launch (no paying customers yet, building features)	Single application surface (web app OR single API), 7 days, OWASP-aligned manual + 1 free retest	Startup Pentest INR 74,999
Pre-launch with payment integration (Stripe, Razorpay)	Web app + payment endpoints, scope expanded to webhook + reconciliation logic	Startup Pentest INR 74,999
First enterprise customer asking for pentest report	Web app + public API (2 scopes), 10 days, SOC 2 + ISO 27001 evidence	Growth Pentest INR 1,79,999
Series A diligence (investor asks for pentest report dated within 12 months)	Web app + public API, 10 days, SOC 2 + ISO 27001 evidence, real-world attack simulation	Growth Pentest INR 1,79,999
Series B+ multi-product, multi-region	Multi-scope, multi-environment, custom scope. Typically INR 5L+	Custom (contact us)

Sharp recommendations

If you built a SaaS with Cursor, Lovable, Bolt.new, v0, or Replit Agent and you are about to launch, pentest first. The cheapest insurance against shipping a public CVE on day one is a pre-launch pentest. The same gaps appear across tools and you do not want to discover them through a Twitter thread.

Do not pentest from the developer’s perspective. Vibe-coded apps look right when you read them; the LLM is good at writing code that appears correct. The pentester is testing the deployed behavior, not the code.

Do not assume the framework defaults are secure. They are conventions, not enforcements. RLS off-by-default is a design choice (Supabase), CORS allow-all in dev is a convenience (Vite), service-role keys in environment variables is a normal pattern that becomes a leak in client bundles.

Do plan for a retest. The first pentest finds gaps; the retest validates fixes. Both Cybersecify Startup and Growth plans include 1 free retest.

Where to go from here

If you built a vibe-coded SaaS and are planning to pentest, book a free 30-min call to scope your engagement. We will look at your stack (tool, framework, backend, payment integration, AI features), recommend Startup vs Growth scope, and quote in the same call.

For pricing and inclusions, see Cybersecify Pentest Pricing. For the deliverable format, see our SOC 2 + ISO 27001 ready pentest report sample.

Related: DAST scan vs pentest: why scanner output isn’t a security assessment, How to scope your first pentest, 5 questions to ask your pentest vendor before signing, Pentest Pricing Tiers Explained: INR 50K to 5L+, Vibe-coded app pre-launch security review.

Frequently asked questions

Do I need a pentest for an app built with Cursor or Lovable?

Yes, before launch and before any enterprise customer onboarding. Vibe-coded apps ship faster than human-written code but inherit the same OWASP Top 10 risk surface. The specific failure patterns are predictable: AI assistants frequently generate insecure defaults (overly permissive CORS, missing webhook signature verification, Supabase Row Level Security disabled), expose secrets in client bundles, and skip rate limiting. A pre-launch pentest catches these before they reach paying customers.

What should I check on a Cursor-built SaaS app before launch?

Focus on these areas: Supabase Row Level Security policies, service-role key exposure in client code, Stripe webhook signature verification, authentication state validation on every API route, AI API key exposure, CORS configuration, rate limiting on AI endpoints, and environment variable exposure through NEXT_PUBLIC_ prefix. The per-tool section above covers each in detail.

Which Supabase RLS gaps appear most often in Lovable-built apps?

Tables created without RLS enabled, policies that use auth.uid() but allow SELECT to the anon role, policies on user-owned tables that compare to the wrong column (e.g., id instead of user_id), RLS bypass through Postgres functions executed with SECURITY DEFINER privilege, and joins through views that bypass RLS on the underlying tables.

What is different about pentesting AI-generated code from Bolt.new, v0, and Replit Agent?

Three predictable failure modes specific to AI-generated apps: outdated dependency versions (the LLM was trained on older library docs and scaffolds packages with known CVEs), middleware bypass (auth checks added to specific routes but missing on catch-all routes), and prompt-injection paths in AI features (user input flows directly into LLM prompts without sanitization). The pentest must include dependency CVE scanning, full-route auth coverage testing, and prompt-injection attack-pattern testing.

What is the minimum pentest scope before going live with a vibe-coded SaaS?

Authentication and session handling, authorization and access control (RLS, role-based access, IDOR on every user-scoped resource), payment webhook signature verification, secret exposure scan (client bundle, GitHub history, environment variables), rate limiting on AI endpoints and authentication endpoints, CORS and CSRF posture, dependency CVE scan, and prompt-injection testing on any LLM-backed feature. Skip mobile, deep infrastructure, and physical security for the pre-launch scope; come back to them when an enterprise customer asks.

How much does a pentest cost for a vibe-coded SaaS app?

For a vibe-coded SaaS at pre-launch or pre-Series-A scope, expect INR 75,000 to INR 1,80,000 depending on scope and report depth. Cybersecify Startup Pentest is INR 74,999 (1 scope, 7 days, 6 hours founder-led consulting, 1 free retest). Growth Pentest is INR 1,79,999 (2 scopes, 10 days, 12 hours founder-led consulting, SOC 2 + ISO 27001 evidence, real-world attack simulation, 1 free retest).

When should a vibe-coded SaaS startup pentest before Series A or after?

Pentest before you have paying customers if you handle payment data, personally identifiable information, authentication credentials, or AI features that process user data. Pentest again before Series A diligence (investors usually ask for a pentest report dated within 12 months of the diligence call). Pentest annually thereafter for SOC 2 Type 2 and DPDP Act compliance evidence.