We Scanned AI-Generated Codebases. Here's What We Found.

We built ShipSafe to scan AI-generated code for security vulnerabilities. After running it against hundreds of repos — from weekend MVPs to apps with paying users — we started seeing patterns. The same mistakes. The same vulnerabilities. Over and over.

This isn't a scare piece. This is data from real scans. Here's what AI-generated codebases actually look like from a security perspective.

The numbers

Across the repos we've scanned, here are the most common findings:

• •34% of repos had at least one exposed API key. OpenAI keys, Stripe live keys, Supabase service role keys, Firebase API keys — hardcoded directly in source files. Not in env vars. Not in a secrets manager. Right there in the code, pushed to GitHub.
• •41% had API routes with no authentication. Endpoints that create, read, update, or delete user data — accessible to anyone who knows the URL. No session check. No token validation. Nothing.
• •28% had at least one SQL injection vulnerability. Raw user input concatenated into database queries. The oldest vulnerability in the book, and AI coding tools still produce it regularly.
• •62% had dependencies with known CVEs. Outdated npm packages with published exploits. Most of these are fixable with a single npm audit fix command.
• •73% had console.log statements in production code. Debug logging that leaks user data, tokens, and internal state to anyone who opens browser dev tools.

The most dangerous finding: exposed API keys

This is the one that costs people money. Real money. We've seen OpenAI keys sitting in frontend code that, if discovered, would let anyone make unlimited API calls billed to the developer's account.

The pattern is always the same. The developer is in a chat with an AI tool. They paste their API key into the conversation to test something. The AI writes it into the code. The developer pushes to GitHub. Even if they later move the key to an env var, the key is still in their git history.

We've seen this with:

• •OpenAI keys (sk-proj-...) — the most common by far
• •Stripe live keys (sk_live_...) — direct access to payment processing
• •Supabase service role keys — bypasses all Row-Level Security
• •AWS access keys (AKIA...) — access to cloud infrastructure
• •Database connection strings — username, password, and hostname in one string

Unprotected API routes: the silent killer

This one doesn't show up on your credit card bill, so people don't notice it. But it's arguably worse.

When you ask AI to "create an API endpoint that deletes a user," it creates one. It handles the database query, returns the right status code, and maybe even sends a confirmation email. What it doesn't do is check whether the person making the request is actually authorized to delete that user.

We consistently find:

• •Admin endpoints with no auth — user management, data exports, configuration changes
• •Data endpoints that return any user's data when given their ID — no ownership check
• •Mutation endpoints that let any authenticated user modify any other user's data
• •Webhook handlers that process events without verifying the signature

SQL injection is alive and well

You'd think in 2026, with ORMs and query builders everywhere, SQL injection would be dead. It's not.

AI tools — especially when building quick prototypes — frequently write raw SQL queries with string interpolation. The code works perfectly in development when you type "john@example.com" into the email field. It also works perfectly when someone types ' OR 1=1; DROP TABLE users; --.

The fix is always parameterized queries. Use your ORM's query builder. Use .eq() instead of string concatenation. This is a one-line change in most cases, but AI doesn't make it by default.

The dependency problem

62% of repos had dependencies with known CVEs. This isn't because developers are careless — it's because AI suggests packages from its training data, which is months or years old.

When ChatGPT suggests npm install next@13.4.1, it's suggesting the version it was trained on — not the latest version. And Next.js 13.4.1 has three known CVEs including a Server-Side Request Forgery vulnerability.

The fix: always run npm audit after installing packages, and use npx npm-check-updates to find outdated dependencies. Better yet, add it to your CI pipeline so it runs on every push.

What the safety scores look like

When we grade repos on our A-F scale:

• AOnly 12% of first-time scans score an A. These repos typically use established auth providers, have RLS enabled, and keep secrets in env vars.
• B23% score a B. Usually one or two medium-severity issues — console.log statements, a missing CORS header, or an outdated dependency.
• C31% score a C. Multiple issues across categories. Typically missing rate limiting, some unprotected routes, and a few medium-severity findings.
• F34% score an F on first scan. At least one critical vulnerability — exposed keys, SQL injection, or completely unprotected admin routes.

The good news: most issues are fixable in under an hour. The playbook changes are specific and actionable. After fixing the findings from their first scan, most developers score a B or higher on their second scan.

The takeaway

AI-generated code isn't inherently bad. It's just unreviewed. The same way you'd review a junior developer's pull request, you need to review AI-generated code for security issues. The difference is that AI produces code much faster than a junior developer, so the volume of unreviewed code is much higher.

That's why we built ShipSafe. You can keep building fast with AI. Just run a scan before you ship.