Vibe Coding Security: How to Keep AI-Generated Apps Safe

The Security Reality

AI-generated code is not inherently more or less secure than human-written code. The same vulnerabilities that plague traditional development — SQL injection, XSS, insecure authentication — can appear in vibe coded apps. The difference is that vibe coders may not recognize these issues because they didn't write the code themselves.

This guide covers the most important security practices for anyone shipping vibe coded applications to real users.

The Top 5 Security Risks in Vibe Coded Apps

1. Exposed API Keys

The problem: AI tools often place API keys directly in frontend code or environment files that get committed to Git.

The fix:
• Never put API keys in files that start with NEXT_PUBLIC_ unless they're meant to be public
• Use server-side API routes to proxy calls to external services
• Add .env.local to your .gitignore before your first commit
• Use Cloudflare Workers secrets or Vercel environment variables for production

2. Missing Row Level Security (RLS)

The problem: Supabase tables default to public access. If you enable RLS but don't add policies, everything is blocked. If you don't enable RLS, everything is open.

The fix:
• Enable RLS on every table that contains user data
• Add policies that scope data to the authenticated user: auth.uid() = user_id
• Test policies by switching between user accounts
• Never rely on frontend-only access control

3. Insecure Authentication Flows

The problem: AI might generate simplified auth that skips important steps like email verification, rate limiting on login attempts, or proper session management.

The fix:
• Use established auth providers (Supabase Auth, NextAuth, Clerk) instead of custom implementations
• Enable email verification for signups
• Add rate limiting to login and signup endpoints
• Implement proper session expiration and refresh token rotation

4. Unvalidated User Input

The problem: AI-generated forms may accept any input without validation, opening the door to injection attacks.

The fix:
• Use Zod or similar schema validation on all API routes
• Sanitize HTML content before rendering (to prevent XSS)
• Validate file uploads: check file type, size, and content
• Never pass user input directly to database queries — use parameterized queries

5. Overly Permissive CORS

The problem: AI often sets Access-Control-Allow-Origin: * to make things work quickly, which allows any website to call your API.

The fix:
• Set CORS to your specific domain: Access-Control-Allow-Origin: https://yourdomain.com
• Only allow the HTTP methods your API actually needs
• Be restrictive with allowed headers

Security Checklist for Launch

Before going live with real users, verify each of these:

☐All API keys are in environment variables, not in code

☐.env.local is in .gitignore

☐RLS is enabled on all Supabase tables with proper policies

☐Authentication uses an established provider (not custom)

☐All API routes validate input with Zod or similar

☐CORS is restricted to your domain

☐HTTPS is enforced (Cloudflare and Vercel do this automatically)

☐Error messages don't leak internal details (stack traces, query structures)

☐File uploads are validated and stored in a separate service (not your database)

☐Rate limiting is in place on authentication and public API routes

Tool-Specific Security Notes

Cursor / Windsurf

These tools give you full code access. You're responsible for reviewing security-sensitive code (auth routes, database queries, API handlers). Use the AI chat to ask: "Are there any security vulnerabilities in this file?"

Lovable

Lovable generates Supabase RLS policies automatically, but they may be too permissive. Review the policies in Supabase Dashboard → Authentication → Policies after generation.

Bolt

Bolt runs in the browser using WebContainers. For production, you'll need to add proper backend security when you deploy outside of Bolt.

When to Get a Security Audit

If your application handles any of the following, consider a professional security review before launch:

Financial data or payments (beyond basic Stripe Checkout)

Health or medical information (HIPAA requirements)

Data from children under 13 (COPPA requirements)

Enterprise customer data with contractual security requirements

Authentication for more than 1,000 users

For most MVPs and early-stage products, following the checklist above is sufficient. Scale your security investment with your user base and data sensitivity.

Further Reading

How to Add Authentication

Supabase RLS Troubleshooting

Stripe Webhook Security