PMaker home
AI writes code fast and often — and it writes these three old flaws fluently tooHardcoded secretsAPI keys and database passwords written directly into code and committedOnce in the cloud, the secret is public — and the bill lands on youBroken access controlChecks "are you logged in" but not "can you see this record"A logged-in user can view others' orders or edit their profilesInjectionUser input concatenated straight into SQL, commands, or HTMLTreats data as instructions — the code-world cousin of prompt injectionAI is the assembly line; you're the inspector. A fast line doesn't mean the product passed

AI doesn't leave bugs on purpose — it faithfully reproduces the "common practice" it learned, and common practice happens to be full of these three traps.

Common Flaws in AI Code

Hardcoded secrets, broken access control, injection — the ones AI leaves most often.

Using AI for code boosts your output, but one thing doesn't improve by itself: security. The code AI produces trips over the same few kinds of flaws, again and again — and it writes them fluently.

Symptoms you'll recognize:

  • The API key sits right there in the config of AI-generated code.
  • An endpoint checks login but not permission — a logged-in user can see anyone's data.
  • User input is concatenated straight into a database query.

Three recurring flaws

  • Hardcoded secrets. API keys, database passwords, and signing keys written directly into code and committed to the repo. The most common flaw in AI-generated code, because sample code and tutorial blogs are full of it. Once the code lands in a repo and goes to the cloud, the secret is effectively public — attackers use it for legitimate-looking calls, and the bill lands on you.
  • Broken access control. The endpoint checks "are you logged in" but not "can you see this record." User A can view user B's orders or edit user B's profile. This is the broken object-level access that has been a regular on the OWASP lists for years. AI-generated CRUD endpoints especially tend to miss this layer — they default to "logged in means allowed." idor-wiki
  • Injection. User input concatenated straight into SQL, shell commands, or HTML. It's the code-world cousin of prompt injection — the same essence: treating data as instructions. AI tends to use string concatenation, which happens to be the most dangerous style. sql-injection-wiki

These three share one trait: they aren't exotic exploits; they're basic security habits. A tool won't build habits for you — it just reproduces the most common patterns it has seen.

Why AI is prone to them

Three reasons, all tied to how AI works:

  • It learns "common practice." AI learns how code is generally written. Public code is full of hardcoded keys and permission-less examples — so what it learned as "normal" happens to be insecure. Ask it to write code that connects to a database, and it defaults to a hardcoded password.
  • It only sees a snippet. When generating a block of code, it can't see your permission system, secret management, or security standards. It doesn't know what your environment variables are called, so it writes the key into the code to make things work.
  • It optimizes for "it runs," not "it's safe." The goal of generation is a working, runnable task. Security is an implicit quality requirement; unless you ask for it in the prompt, it won't add it.

So stop asking why AI writes insecure code — ask why you didn't review it. Speed doesn't equal quality, and the security line is always held by a human.

A review checklist

Whether the code came from AI or a human, walk this checklist before shipping: owasp-top10

  • Scan for secrets. Any hardcoded keys, passwords, or tokens in the repo? Run a scan across everything. Put secrets in environment variables or a secret manager. If a secret was already committed, revoke and rotate it immediately — deleting it isn't enough.
  • Check every endpoint's authorization. Ask of each one: does it check login? Does it check whether the current user can access this specific record? The test is simple — use A's session to access B's resource and see if it's blocked.
  • Check every place things get "concatenated." Anywhere user input (or any external input) flows into a query, command, or HTML must use parameterized code, not string concatenation.
  • Make the AI review itself first. Add one line to your prompt: "Write a security-compliant version: no hardcoded secrets, every endpoint checks authorization, all user input is parameterized." It works immediately. Putting security requirements in the prompt is the cheapest line of defense.
  • Make review a process. AI code goes through the same review, testing, and scanning as human code. Don't relax review because the volume went up — precisely because the volume went up, review matters more.

Remember: AI is the assembly line; you're the inspector. A fast line doesn't mean the product passed.

References

  1. OWASP Top 10:2025
  2. SQL injection — Wikipedia
  3. Insecure direct object reference — Wikipedia