Security Guide for Apps Built with Cursor, Bolt, and Replit

Cursor, Bolt, Replit, Lovable, and v0 have unlocked a new wave of indie developers and solo founders shipping apps faster than ever. The products are real, the users are real — and so are the security vulnerabilities. This guide covers the specific, tool-generated vulnerability patterns we see most often, categorized by which AI coding tool tends to produce them.

Common Security Issues in Cursor-Generated Apps

Cursor is the most widely used AI coding assistant for building full-stack apps. It excels at generating Next.js API routes, database schemas, and authentication flows. It consistently falls short in several security areas:

Next.js API Route Authorization Gaps

Cursor-generated Next.js API routes typically use Supabase Auth or NextAuth for authentication. The auth check is almost always present. What's frequently missing is the authorization check. A route that fetches /api/orders/[id] will verify the user is authenticated, then query the database with only the order ID — no check that the order belongs to the authenticated user. This is textbook IDOR.

Supabase RLS Not Enabled

Cursor commonly generates Supabase schemas and API routes without enabling Row Level Security (RLS) policies. When RLS is disabled, any query against a table returns all rows regardless of user — your service role key queries are scoped, but direct table access from the client SDK is completely open.

Admin Routes Protected Only by Client-Side Checks

Cursor frequently generates admin dashboards that hide navigation links for non-admins in the UI but don't enforce the restriction in the API routes. The frontend check is cosmetic. An attacker who knows (or guesses) the admin API endpoint URL can call it directly with any valid JWT.

Common Security Issues in Bolt-Generated Apps

Bolt generates full-stack apps rapidly with a focus on React frontends and Node.js backends. Security issues we commonly see in Bolt-generated code:

• CORS configured with wildcard origins (Access-Control-Allow-Origin: *) — a development convenience that gets shipped to production
• Express middleware order issues: auth middleware added after route definitions, meaning the middleware only applies to routes defined after it
• Missing input validation: user-provided parameters used directly in database queries or file system operations without sanitization
• Environment variables hardcoded in source files instead of .env, leading to API key exposure when code is pushed to GitHub

Common Security Issues in Replit-Generated Apps

Replit apps are often deployed from a shared development environment, which introduces specific security concerns beyond typical code vulnerabilities:

• Secrets in Replit environment variables that are visible to collaborators — appropriate for development, dangerous if a collaborator is untrusted
• Debug endpoints left enabled in production (common in Flask/FastAPI-based Replit apps)
• SSRF through user-controlled URL fetching: AI-generated URL preview or webhook validation features that don't restrict which hosts can be fetched
• SQLite path traversal: Replit apps using SQLite with user-controlled file paths can be vulnerable to reading arbitrary files

Common Security Issues in Lovable and v0 Apps

Lovable and v0 generate primarily React frontend code with Supabase as the backend. The security issues tend to concentrate in the Supabase configuration:

• Client-side Supabase queries without RLS: queries made directly from the React frontend with the public anon key, with no RLS policies to restrict data access
• Exposed Supabase service role key: occasionally generated configuration files include the service role key (which has full database access) in client-facing code
• Missing realtime subscription filters: Supabase realtime channels without row-level filters, broadcasting all users' updates to all subscribers

Universal Security Checks for All Vibe-Coded Apps

Regardless of which tool built your app, run these checks before going to production:

1. Create two user accounts. For every data endpoint, try accessing user A's data while logged in as user B by changing the ID in the URL or request body.
2. Navigate to /admin while logged in as a regular user. Also try /admin/users, /api/admin, /api/internal. Do you get 401/403, or do you get data?
3. Make 100 rapid login attempts with wrong credentials. Measure whether rate limiting kicks in.
4. Check your HTTP response headers at securityheaders.com or in your browser's Network tab. Look for Content-Security-Policy, X-Frame-Options, and HSTS.
5. Search your codebase for your API keys and secrets. Run git log --all -p | grep 'API_KEY\|SECRET\|PASSWORD' to check if they've ever been committed.
6. Review your CORS policy. Search for 'cors' in your codebase and verify origins are restricted to your production domain.

For a comprehensive automated scan that covers all of these and more, Pentrust runs AI agents specifically designed to find the vulnerability patterns that AI coding tools generate. A full scan takes under 30 minutes and gives you confirmed vulnerabilities with copy-paste fixes.