20 Ways Your Vibe-Coded App Gets Hacked (And Exactly How to Fix Them) ⚡

1. 1. Committing `.env` Secrets to GitHub
2. 2. Exposing Private API Keys in Frontend Code
3. 3. Disabling Row-Level Security (RLS) on Database
4. 4. Relying Exclusively on Frontend Permission Checks
5. 5. Missing Rate Limiting on API Endpoints
6. 6. SQL Query String Concatenation (SQL Injection)
7. 7. Zero Server-Side Input Validation (Zod / Joi)
8. 8. Rendering Untrusted User Input as Raw HTML (XSS)
9. 9. Storing Plaintext Passwords (Missing Argon2 / Bcrypt)
10. 10. Storing Sensitive Auth Tokens in localStorage
11. 11. Unauthenticated Admin Panel Routes & Endpoints
12. 12. Permissive Wildcard CORS (`Access-Control-Allow-Origin: *`)
13. 13. Missing Email Verification on User Signups
14. 14. Predictable Sequential IDs Without Ownership Verification (IDOR)
15. 15. Mass Assignment by Saving Raw `req.body` to Database
16. 16. Accepting Webhooks Without Cryptographic Signature Verification
17. 17. Leaking Detailed Stack Traces & Debug Info in Production
18. 18. Abandoned Dependencies with Known CVEs
19. 19. Zero Password Strength Checks & Pwned Password Audits
20. 20. Unrestricted File Uploads Without MIME / Size Validation
21. ⚡ The 1-Click Master Codebase Audit Prompt

1. Committing `.env` Secrets to GitHub

The Risk: Automated scrapers scan public and private GitHub commits within seconds, extracting Stripe secret keys, database credentials, and OpenAI API tokens.

The Fix: Add `.env*` to `.gitignore` immediately. Use secret managers (e.g., Vercel Environment Variables, AWS Secrets Manager) and configure git pre-commit hooks with tools like git-secrets or trufflehog.

2. Exposing Private API Keys in Frontend Client Bundles

The Risk: Hardcoding OpenAI, Anthropic, or database admin keys in Next.js/React client components exposes them in browser source maps and network requests.

The Fix: Keep all paid and administrative API calls inside server-side route handlers (e.g., /api/generate) or Next.js Server Actions. Never prefix secret keys with NEXT_PUBLIC_ or VITE_.

3. Disabling Row-Level Security (RLS) on Database

The Risk: When Supabase or PostgreSQL RLS is turned off, any user with your public anon key can query, mutate, or delete every row across your entire database table via the client SDK.

The Fix: Always enable RLS on every table (ALTER TABLE my_table ENABLE ROW LEVEL SECURITY;) and enforce strict tenancy policies (e.g., auth.uid() = user_id).

4. Relying Exclusively on Frontend Permission Checks

The Risk: Hiding a button or redirecting in React (e.g., if (!isAdmin) return null;) does not protect the underlying API endpoint. Attackers can call the REST or GraphQL endpoint directly.

The Fix: Verify user authentication, roles, and resource ownership inside every backend endpoint handler and middleware.

5. Missing Rate Limiting on API Endpoints

The Risk: Attackers can drain your LLM tokens ($10,000+ overnight API bills), spam registration endpoints, or brute-force login credentials.

The Fix: Implement Redis-backed token bucket rate limiters (e.g., Upstash Rate Limit, express-rate-limit) per IP address and authenticated user ID.

6. SQL Query String Concatenation (SQL Injection)

The Risk: Writing raw queries like `SELECT * FROM users WHERE email = '${email}'` allows attackers to inject malicious SQL commands, bypass auth, or dump tables.

The Fix: Use parameterized queries or type-safe ORMs (Prisma, Drizzle, Kysely) that automatically escape all query inputs.

7. Zero Server-Side Input Validation (Zod / Joi)

The Risk: Malformed payloads, negative pricing numbers, or excessively long strings can crash server workers or trigger arithmetic logic flaws.

The Fix: Define strict schema validation using Zod on every incoming API request before executing database queries or business logic.

8. Rendering Untrusted User Input as Raw HTML (XSS)

The Risk: Using dangerouslySetInnerHTML or unescaped template literals allows attackers to execute arbitrary JavaScript in other users' browsers, stealing session cookies and auth credentials.

The Fix: Sanitize all HTML using DOMPurify on both server and client, or render plain text nodes with standard React JSX escaping.

9. Storing Plaintext Passwords

The Risk: A database leak immediately exposes customer passwords across other accounts.

The Fix: Never store raw passwords. Use industry-standard cryptographic hashing functions like Argon2id or Bcrypt (with salt rounds >= 12), or delegate auth to managed providers (Supabase Auth, Clerk, Auth0).

10. Storing Sensitive Auth Tokens in localStorage

The Risk: Any Cross-Site Scripting (XSS) flaw or compromised third-party npm package can read localStorage.getItem('token') and exfiltrate user sessions.

The Fix: Store JWT session tokens in HttpOnly, Secure, SameSite=Strict cookies that cannot be accessed by client-side JavaScript.

11. Unauthenticated Admin Panel Routes

The Risk: AI vibe-coders often build routes like /admin/users or /api/admin/metrics assuming obscurity protects them.

The Fix: Protect administrative routes with edge middleware verifying server-validated role === 'admin' claims and multi-factor authentication (MFA).

12. Permissive Wildcard CORS (`Access-Control-Allow-Origin: *`)

The Risk: Wildcard CORS headers combined with authenticated session cookies allow malicious third-party websites to forge requests on behalf of logged-in users.

The Fix: Restrict allowed origins strictly to your production and staging domains (e.g., https://app.somyanayak.com).

13. Missing Email Verification on Signups

The Risk: Attackers create fake accounts with legitimate victims' emails, generating automated spam, hijacking prospective user accounts, and poisoning analytics.

The Fix: Enforce mandatory double-opt-in email verification links with short TTL tokens before granting write permissions or workspace access.

14. Predictable Sequential IDs Without Ownership Checks (IDOR)

The Risk: If invoice URLs are formatted as /api/invoices/1042, an attacker simply iterates to 1043, 1044 to scrape every customer's billing data (Insecure Direct Object Reference).

The Fix: Use non-sequential UUIDs (v4 / v7) or nanoids, and always verify object-level ownership: WHERE id = :invoiceId AND user_id = :currentUserId.

15. Mass Assignment by Saving Raw `req.body`

The Risk: Code like db.update(req.body) allows malicious users to pass { role: "admin", plan: "enterprise", credits: 99999 } in JSON update requests.

The Fix: Whitelist only editable fields explicitly using Zod (e.g., z.object({ name: z.string(), bio: z.string() })) before updating records.

16. Webhooks Processed Without Signature Verification

The Risk: If your Stripe or payment webhook endpoint accepts raw JSON without checking stripe-signature, anyone can forge payment success events to get free subscriptions.

The Fix: Use official SDK webhook constructors (e.g., stripe.webhooks.constructEvent(rawBody, signature, secret)) using the raw unparsed request buffer.

17. Leaking Detailed Stack Traces in Production

The Risk: Unhandled exceptions returning full stack traces reveal server file paths, framework versions, database table names, and internal package logic.

The Fix: Wrap global error handlers to return generic error messages (e.g., "Internal Server Error") to clients while logging full traces securely to Sentry or Datadog.

18. Abandoned Dependencies with Known CVEs

The Risk: Using vulnerable third-party packages exposes your server to Remote Code Execution (RCE) and prototype pollution.

The Fix: Run automated dependency audits in CI/CD pipelines (npm audit, pnpm audit, Snyk, or Dependabot) and maintain lockfiles.

19. Zero Password Strength Checks & Breach Audits

The Risk: Users setting passwords like "password123" are vulnerable to credential stuffing attacks from previous corporate leaks.

The Fix: Enforce minimum length (>= 12 chars), complexity rules, and integrate the HaveIBeenPwned k-Anonymity API to reject known breached passwords.

20. Unrestricted File Uploads Without Validation

The Risk: Allowing users to upload files without validating MIME types, extensions, and file headers enables attackers to upload executable PHP/JS scripts or SVG cross-site scripting vectors.

The Fix: Validate file magic bytes (not just extension), enforce strict size limits (< 5MB), strip metadata, and store uploads in isolated object storage buckets (S3 / Cloudflare R2) with randomized filenames.