All checks

AI-generated code security risks: what your copilot won't warn you about

GuideQuick + Deep· 4 min read· Last updated

SHORT ANSWER

AI tools like Cursor, Lovable, Replit, Bolt and Base44 write code that works, but they don't think about who else can call it. The three most common problems are API endpoints with no authentication, secrets hardcoded or in public environment variables, and business logic that trusts whatever the browser sends. These aren't edge cases. They show up in almost every AI-generated codebase we scan.

The pattern: it works, so it ships

When you tell an AI to "add a Stripe checkout" or "create a user profile page", it builds the feature. It doesn't ask: can an unauthenticated user call this endpoint? Can someone change the price in the request body? Is this API key safe in a VITE_ variable?

The code passes every manual test you run while logged in. The problem is what happens when someone who isn't you sends a request.

The 7 most common risks in AI-generated code

1. API endpoints with no auth check

The AI creates /api/users, /api/orders, /api/admin/settings. They all work. None of them check whether the caller is signed in, let alone whether they have the right role.

What to check: Open every API route and server action. Look for a session or token check in the first few lines. If the route jumps straight into database queries, it's open to anyone.

2. No ownership verification (IDOR)

/api/orders/123 returns order 123. The endpoint checks that the user is signed in, but not that order 123 belongs to them. Any signed-in user can read any order by changing the ID.

What to check: For every endpoint that takes an ID parameter, confirm it filters by the current user's ID, not just by the record ID.

3. Hardcoded secrets

The AI pastes an API key into the code "to make it work." It ends up in the git history even if you delete it later.

What to check: Search for sk_, sk-, secret, password, service_role, api_key in your codebase. Check that .env is in .gitignore. Check your git history: git log -p -S "sk_".

4. Secrets in public environment variables

NEXT_PUBLIC_, VITE_, REACT_APP_, EXPO_PUBLIC_ — anything with these prefixes ships to every visitor's browser. The AI doesn't distinguish between a publishable key and a secret key.

What to check: List every environment variable with a public prefix. Only publishable/anon keys belong there. Stripe secret keys, Supabase service_role keys, OpenAI keys — never.

5. Client-side trust

The price comes from the request body. The plan name comes from a hidden form field. The user role comes from localStorage. The AI built it that way because it was the fastest path to "it works."

What to check: Find every place your app handles money, plans, credits, or roles. Confirm the value comes from your database or payment provider, not from the request.

6. Database rules left open

Supabase apps without Row Level Security. Firebase apps with ".read": true. The AI enables broad access to get the app working and never tightens it.

What to check: In Supabase, check every table for RLS enabled and policies that verify ownership. In Firebase, read your security rules file for true or auth != null without ownership checks.

7. Outdated dependencies

The AI's training data includes older package versions. It installs packages with known vulnerabilities because that's what it learned from.

What to check: Run npm audit, pip audit, or your package manager's equivalent.

How to protect your API endpoints

Whether your code is AI-generated or not, every API endpoint needs:

  1. Authentication: Verify the caller has a valid session or token. Reject unauthenticated requests with 401.
  2. Authorization: Verify the caller has permission to perform this action. A signed-in user is not automatically an admin.
  3. Ownership: If the endpoint accesses a specific record, verify the record belongs to the caller.
  4. Input validation: Never trust prices, quantities, roles, or IDs from the request body. Read them from your database.
  5. Rate limiting: Prevent abuse by limiting how many requests a single user or IP can make.

How to scan for these automatically

  1. Connect your GitHub repo (read-only) or upload a zip on SetRepo. Add your live URL if the app is deployed.
  2. A free Quick scan checks for: secrets in code and git history, vulnerable dependencies, public-prefixed secrets, route-level access control gaps, and your live site's security headers.
  3. Each finding comes with a fix prompt you can paste into your AI tool to fix it.
  4. A Deep scan adds an AI-powered review of access control and business logic — the kind of bugs that pattern matching can't catch.

Continue your website review

Use the website security walkthrough to check the live site and access controls, then record the results in the pre-launch checklist. Start a free live URL scan for public-facing checks.

FAQ

Is AI-generated code less secure than hand-written code?

It makes the same mistakes a junior developer would, but faster and at scale. The difference is that a junior developer has a code review process. Most AI-generated apps ship without one.

Can I just tell the AI to "make it secure"?

It helps, but it's not reliable. The AI may add a session check to the endpoint you asked about and miss the other 12 endpoints. An automated scan catches what instructions miss.

Does SetRepo work with any AI tool?

Yes. It scans the code output, not the tool. Whether you used Cursor, Lovable, Bolt, Replit, Base44, or wrote it by hand, the scan works the same way.

What does it cost?

The Quick scan is free with no credit card. A Deep scan is a one-time payment, and there are monthly plans if you scan often. See setrepo.com/pricing.

Scan your AI-built app, free.

Start free scan