Why Your AI-Built API Is a Security Risk

Your API Does Exactly What You Asked For

When you tell an AI to "build a REST API for users," it builds endpoints that create, read, update, and delete users. It connects to your database, returns JSON, and handles the basic CRUD operations. If you ask for it, you get pagination too.

What it doesn't build: authorization middleware, input validation, rate limiting, or output filtering. The AI delivers endpoints that do precisely what you described — and nothing more. The API works perfectly in your testing. It also works perfectly for anyone else who finds it.

We've audited dozens of vibecoded products over the past year. The pattern is consistent: the app works, the founder is thrilled, and the API layer is hiding vulnerabilities that would fail any serious security review. Not because the AI wrote bad code, but because nobody prompted it to write secure code.

This is especially common in products built with Cursor, Bolt, or similar AI tools where the developer is moving fast and verifying by clicking through the UI. The API surface is invisible from the browser — and invisible problems don't get caught until someone exploits them.

The Five Most Common API Vulnerabilities in AI Code

These are the issues we find in almost every AI-generated codebase we review. They map directly to the OWASP Top 10 API security risks, and they're all preventable.

1. Broken Object-Level Authorization (IDOR)

GET /api/users/123 returns user 123's data regardless of who's asking. The AI builds the endpoint to fetch a record by ID, but it never checks whether the requester has permission to see that record.

This is the number one vulnerability we find. It's called an IDOR (Insecure Direct Object Reference), and it means any authenticated user can access any other user's data by changing the ID in the request. Profiles, orders, invoices, messages — anything with a sequential or guessable ID is exposed.

The AI doesn't add the check because you didn't ask for it. You said "build an endpoint to get a user by ID," and that's what it built. The concept of authentication vs authorization is a distinction the AI rarely makes on its own. It will verify that someone is logged in, but not that they're allowed to access the specific resource they're requesting.

2. Mass Assignment

POST /api/users accepts any field in the request body — including role: "admin" or isVerified: true. The AI takes the incoming JSON and passes the entire object to the database create or update operation without filtering which fields are allowed.

In practice, this means an attacker can escalate their own privileges by including fields that should only be set by the system. We've seen this in production apps where a regular user could make themselves an admin by adding one extra field to a signup request.

3. Excessive Data Exposure

GET /api/users returns password hashes, internal IDs, email addresses, creation timestamps, and every other column in the database table. The API serializes the full database record and sends it to the client.

Even if your frontend only displays the user's name and avatar, the full response is visible in browser DevTools to anyone who cares to look. This leaks information that makes every other attack easier — internal IDs for IDOR attacks, email addresses for phishing, and metadata that reveals your data model.

4. Missing Rate Limiting

Every endpoint accepts unlimited requests. There's no throttling, no abuse prevention, no request budgets. A single script running in a loop can brute-force login credentials, drain your API compute budget, scrape your entire user database, or trigger thousands of password reset emails.

AI-generated APIs almost never include rate limiting because it's a cross-cutting infrastructure concern, not a feature-level one. No individual prompt produces it. You won't notice the absence until someone exploits it — and by then you're dealing with the fallout.

5. No Input Validation

The API trusts that request bodies and query parameters contain valid data. Strings arrive where numbers are expected. Payloads contain megabytes of data. Query parameters include SQL injection payloads or XSS scripts. None of it gets rejected at the API boundary.

The AI generates code that works when it receives the expected input shape. It doesn't generate code that rejects unexpected input. This is the difference between "works in development" and "survives in production."

Why AI Gets APIs Wrong

The underlying issue is straightforward: AI coding tools optimize for "does the endpoint return the right data for a valid request." Security is a cross-cutting concern — it's not part of any single feature prompt. When you ask for a user endpoint, you get a user endpoint. You don't get the middleware, validation, and filtering that makes that endpoint safe.

The AI also has no context about your threat model. It doesn't know whether your API is internal or public, whether your users are trusted employees or anonymous internet users, or whether the data you're serving is public or sensitive. Without that context, it defaults to the simplest implementation — which is invariably the least secure one.

There's a training data problem too. Most code examples and tutorials that AI models learned from are written for teaching, not for production. Tutorials skip security for brevity and clarity. The AI inherits that pattern: build the feature, skip the guardrails. We wrote about this broader pattern in our post on the vibecoding trap — AI tools produce code that works for demos but breaks under real-world conditions.

How to Check Your API Right Now

You don't need a professional penetration testing engagement to find these issues. You can catch the worst problems in an afternoon with browser DevTools and a terminal.

Test for IDOR vulnerabilities. Log in as one user. Open DevTools, go to the Network tab, and use your app normally. Find any API request that includes an ID — user profiles, orders, documents. Copy that request as a curl command, change the ID to a different user's, and run it. If you get back another user's data, you have an IDOR.

Test for mass assignment. Look at your create or update endpoints. Send a request with extra fields that shouldn't be user-controllable: role, isAdmin, verified, credits. If the API accepts them and the values show up in the database, you have a mass assignment vulnerability.

Check response payloads. Look at the JSON your API returns. If you see password hashes, internal database IDs, email addresses of other users, or any field that the frontend doesn't actually display, your API is leaking data.

Send unexpected input. Put strings in number fields. Send a 10MB JSON body. Include special characters like ', ", <script>, and ${7*7} in text fields. If the API processes these without rejecting them, your input validation is missing.

Inspect your middleware chain. Open your route definitions and trace the middleware. Is there auth middleware on every protected route, or only on some? A common AI pattern is to add authentication to the routes it generated first and forget the rest.

Look for rate limiting. Hit your login endpoint 100 times in rapid succession with curl in a loop. If every request gets processed, you have no rate limiting on the most critical endpoint in your application.

For a more thorough walkthrough, our audit checklist post covers the full process including database performance, secrets management, and error handling.

The Fix List

Prioritize these in order. Each one addresses a class of vulnerability, and the earlier items on the list prevent the most damaging attacks.

Add authorization middleware to every endpoint. Not just authentication — authorization. Every request that accesses a specific resource must verify that the requesting user has permission to access that specific resource. This is a code review priority for any AI-generated API.

Implement allowlists for request body fields. Never pass the raw request body to your database. Define exactly which fields each endpoint accepts, and strip everything else. In Express, this means destructuring the specific fields you want. In frameworks with ORMs, use mass-assignment protection features.

Create response DTOs or serializers. Define explicit response shapes that specify exactly which fields get returned to the client. Never serialize a database record directly. This prevents data leaks and gives you a clear contract between your API and your frontend.

Add rate limiting — especially on auth and payment endpoints. Use middleware like express-rate-limit or your platform's built-in rate limiting. Start with aggressive limits on login, signup, password reset, and any endpoint that costs you money. You can relax limits later; you can't un-breach your users' accounts.

Validate all input with a schema validator. Use Zod, Joi, or a similar library to define the expected shape, type, and constraints of every request. Reject anything that doesn't match before it reaches your business logic. This is your first line of defense against injection attacks and malformed data.

These fixes aren't optional polish. They're the difference between an API that works and an API that's safe to put in front of real users with real data.

---

Related glossary terms: API · IDOR · Rate Limiting · SQL Injection · Authentication vs Authorization · OWASP Top 10 · Penetration Testing · Code Review