Your AI coding tool won't tell you about these security holes

AI coding tools are optimized to generate code that satisfies the prompt. A prompt that says "build me a user dashboard with a list of their orders" produces a dashboard with a list of orders — it does not produce rate limiting, it does not produce server-side session verification on the orders API route, it does not produce a Content Security Policy, and it does not produce Row Level Security policies in the database. None of those things were in the prompt. The tool did exactly what it was asked. This is not a flaw in the tools — it is a description of how they work. They learn from code that exists, and most existing code does not include robust security controls. They generate what developers in their training data wrote, which is mostly code that works, not code that is hardened against adversarial input.

There are five specific security categories that AI coding tools miss consistently, regardless of which tool you use. The first is authentication on non-UI routes. When you ask an AI tool to add an admin panel or a data export feature, it creates the UI and the backend route, but the route often has no authentication check — the UI hides the link, but the endpoint is publicly accessible at its URL. The second is rate limiting. AI tools generate login forms, API endpoints, and contact forms without any throttling mechanism, because rate limiting requires infrastructure configuration (Redis, middleware) that is not part of the default scaffold. The third is security headers — no AI builder I am aware of configures X-Frame-Options, CSP, or HSTS by default in a new project, despite these being well-understood requirements for any web app. The fourth is database-layer access control: AI tools know how to write Supabase queries but do not generate RLS policies because those require understanding your authorization model, which the tool does not have. The fifth is secrets management: AI tools will write code that uses environment variables, but they will not audit which variables belong server-side and which are safe for the client.

The fact that your code passes a linter or TypeScript type check is not evidence that it is secure. Linters check for code style and potential runtime errors. TypeScript checks that your types are consistent. Neither tool models what an attacker does with your endpoint when they send an unexpected payload, an out-of-range value, or a request they are not supposed to be making. The gap between "type-safe, lint-clean code" and "code that cannot be abused" is exactly where the security vulnerabilities live. An AI tool that generates fully typed, lint-clean code can still generate an endpoint that returns any user's order if you pass their order ID in the URL parameter — because the type is correct, but the authorization check is absent.

Business logic authorization is the hardest category to automate because it requires knowing what your application is supposed to do and who is supposed to be able to do it. An AI tool generating a CRUD API for a multi-user app will typically produce endpoints that accept an entity ID and return or modify the corresponding record. It will not automatically add a check that the entity belongs to the requesting user, because it does not know whether entities are user-scoped or shared. This produces what security professionals call an IDOR vulnerability — Insecure Direct Object Reference — where a user can access another user's data by substituting their entity ID in a request. IDOR vulnerabilities are among the most commonly reported findings in bug bounty programs and among the easiest for an attacker to exploit, but they are invisible to static analysis tools and will not appear in a lint output.

The practical implication is that AI-built apps need a complementary layer of testing that checks what the tools cannot check. The most effective approach combines an automated scanner against your live app — which can catch the category-level gaps like missing headers, exposed keys, and accessible env files — with manual authorization testing, where you log in as one user and attempt to access another user's data by modifying IDs in API requests. Neither approach requires a security background. The automated scanner produces a list of findings with explanations; the manual testing requires only a browser and a second test account. Together they cover the ground that AI tools leave unguarded.