DEV Community

Jakub
Jakub

Posted on

7 Security Holes We Keep Finding in Vibecoded Apps: Audit Vibe Coding by Inithouse

We run Audit Vibe Coding at Inithouse, a security audit tool built specifically for AI-generated projects. After scanning hundreds of vibecoded apps, the same seven vulnerabilities show up over and over. None of them are exotic. All of them are fixable in under five minutes each.

Here they are, with a grep command you can run right now to check your own codebase.

1. Hardcoded secrets in source code

AI code generators love placeholder values. They drop in sk-test-abc123 or API_KEY=your-key-here, and you replace them with real credentials during development. Then you forget to move them to environment variables.

We have found live Stripe keys, Supabase service role tokens, and OpenAI API keys sitting in plain JavaScript files.

Check yours (2 min):

grep -rnI \
  "sk-\|sk_live\|sk_test\|api_key\s*=\|apiKey\s*[:=]\|secret_key\|SUPABASE_SERVICE_ROLE\|password\s*[:=]\s*['\"\"]" \
  src/ lib/ app/ --include="*.ts" --include="*.tsx" --include="*.js" --include="*.jsx"
Enter fullscreen mode Exit fullscreen mode

Any hit that contains a real credential (not a .env reference) is a problem. Move it to .env and add .env to .gitignore.

2. API routes with no authentication

AI generates beautiful CRUD endpoints. It rarely adds auth middleware unless you specifically ask for it. The result: anyone with your API URL can read, create, update, or delete data.

We see this most often in Next.js API routes and Supabase Edge Functions where the generator builds the handler but skips the auth check entirely.

Check yours (3 min):

# Next.js API routes without auth
grep -rL "getServerSession\|getToken\|auth(\|middleware\|supabase.*auth" \
  app/api/ pages/api/ 2>/dev/null

# Supabase Edge Functions without JWT verification
grep -rL "Authorization\|jwt\|verify" \
  supabase/functions/ 2>/dev/null
Enter fullscreen mode Exit fullscreen mode

Files that appear in the output have no authentication logic. Add middleware or a session check before any data operation.

3. SQL injection through string interpolation

Modern ORMs and query builders handle parameterization automatically. But when AI writes raw SQL (or when you ask it to "make a custom query"), it often builds the query with template literals instead of parameterized placeholders.

One vibecoded app we audited had a search endpoint that concatenated user input directly into a Postgres query. Classic injection vector, year 2026.

Check yours (2 min):

grep -rnE "query\s*\(\s*\`|execute\s*\(\s*\`|sql\s*\(\s*\`" \
  src/ lib/ app/ supabase/ --include="*.ts" --include="*.js"
Enter fullscreen mode Exit fullscreen mode

If you see ${userInput} inside a query template literal, replace it with a parameterized query. In Supabase: use .rpc() or the query builder. In raw Postgres: use $1, $2 placeholders.

4. Secrets committed to git history

Even if your .env is now in .gitignore, it might already be in your git history from an earlier commit. AI-generated projects often start without a proper .gitignore, and the first few commits include everything.

Check yours (2 min):

git log --all --diff-filter=A --name-only --pretty=format: | \
  grep -E "\.env$|\.env\.local$|\.env\.production$" | sort -u
Enter fullscreen mode Exit fullscreen mode

If you get results, those files are in your history. If the repo is public (or was ever public), rotate every credential in those files. Use git filter-repo or BFG Repo-Cleaner to scrub the history.

5. CORS wide open in production

AI sets Access-Control-Allow-Origin: * because it works immediately during development. Nobody changes it before deploy. Now any website can make authenticated requests to your API.

Check yours (1 min):

grep -rnE "Access-Control-Allow-Origin.*\*|cors\(\s*\)|origin:\s*true|origin:\s*\*" \
  src/ app/ lib/ next.config.* vite.config.* --include="*.ts" --include="*.js" --include="*.mjs" 2>/dev/null
Enter fullscreen mode Exit fullscreen mode

Replace the wildcard with your actual domain. If you use a framework's CORS middleware, set origin to your production URL explicitly.

6. No rate limiting on authentication

Login, signup, password reset: these endpoints get brute-forced constantly. AI generates the auth flow but almost never adds rate limiting. We regularly find login endpoints that accept unlimited requests per second.

Check yours (3 min):

# Find auth-related endpoints
grep -rn "login\|signin\|signup\|register\|reset.password\|forgot.password" \
  app/api/ pages/api/ src/routes/ supabase/functions/ \
  --include="*.ts" --include="*.js" -l 2>/dev/null

# Then check if those files reference any rate limiting
for f in $(grep -rl "login\|signup\|reset.password" app/api/ pages/api/ src/routes/ 2>/dev/null); do
  grep -L "rateLimit\|rate.limit\|throttle\|limiter" "$f"
done
Enter fullscreen mode Exit fullscreen mode

Files in the second output have auth logic but no rate limiting. Add a limiter (e.g., express-rate-limit, Upstash ratelimit, or Supabase's built-in rate limiting on Edge Functions).

7. Authorization checks only on the frontend

The AI builds a nice admin dashboard with {isAdmin && <AdminPanel />} in React. But the API endpoint behind it serves data to anyone who calls it directly. The frontend hides the button; the backend serves the data regardless.

This is the most common hole we find. Frontend visibility checks create an illusion of security.

Check yours (5 min):

# Frontend role checks (these are UI-only, not security)
grep -rn "isAdmin\|role\s*===\|user\.role\|user\.type\|canEdit\|hasPermission" \
  src/components/ src/pages/ app/ --include="*.tsx" --include="*.jsx" 2>/dev/null

# Now check: do the corresponding API routes verify roles server-side?
grep -rL "role\|admin\|permission\|authorize" \
  app/api/ pages/api/ supabase/functions/ 2>/dev/null
Enter fullscreen mode Exit fullscreen mode

Every permission check in the frontend needs a matching check on the server. If the server endpoint does not verify the user's role, anyone can call it directly with curl or Postman.

The pattern

These seven holes share a root cause: AI generates code that works. "Works" and "secure" are different things. The generator optimizes for functionality, not for defense.

We built Audit Vibe Coding at Inithouse because we kept running into these same issues across our own portfolio of products. The tool runs a scored audit across security, SEO, performance, accessibility, and code quality, then hands you a prioritized list of fixes. No account needed.

Run the grep commands above. If even one returns a hit, your app probably has more issues underneath. That is normal for vibecoded projects. What matters is catching them before someone else does.

Top comments (0)