Security Check for AI Code

Before AI-generated code ships, run it through the security checklist: hardcoded secrets, broken access control, injection—three minutes to avoid one incident.

AI writes code fast and often, but it won't automatically write secure code for you. Its output keeps falling into the same three traps: hardcoded secrets, broken access control, and injection. Run a check before launch—three minutes can prevent one incident.

What you'll run into:

• API keys sitting in plain sight in the code, pushed to the cloud with the repo
• An endpoint that checks "are you logged in" but not "can you see this record"
• User input concatenated straight into a database query string

Three high-frequency traps

Know what the traps look like first, then you know what to check:

• Hardcoded secrets. API keys, database passwords, and signing secrets written straight into the code or committed to the repo. Once the code lands in the repo and the cloud, the secret is public—an attacker uses 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." Logged-in user A can view user B's orders or edit user B's profile. AI-generated CRUD endpoints are especially likely to miss this layer. owasp-bac
• Injection. User input concatenated straight into SQL, commands, or HTML. At its core, it's treating "data" as "instructions"—and when AI generates code it tends to reach for string concatenation, which happens to be the most dangerous pattern. See Prompt Injection. owasp-injection

The three-minute checklist

Whether the code was written by AI or a human, run this checklist before launch:

• One: scan for secrets. Search the whole repo for keys, passwords, and tokens. If you find something already committed, revoke and reissue it immediately—deleting is not enough, because the deleted copy already leaked.
• Two: check every endpoint's permissions. Ask twice per endpoint: does it verify login? Does it verify "this user's access to this record"? The test is simple—use A's session to request B's resource (say, GET /orders/B-1024). A 403 means access is actually checked; a 200 means you only checked "logged in."
• Three: find every place things get "joined." Anywhere user input (or any external input) reaches a query, a command, or HTML, it must use parameterized calls, not string concatenation.
• Four: have the AI self-check first. Add one line to your prompt: "Write the secure version: no hardcoded secrets, every endpoint checks permissions, all user input is parameterized." It's instant and free.
• Five: treat it as a process. AI code goes through the same review, scanning, and testing as human code. Because the volume of code is up, review matters even more. See the launch checklist.

Why AI is especially prone

Three reasons, all tied to how AI works:

• It learns "common patterns." AI learns "how code is generally written" from massive amounts of public code—and public code is full of hardcoded secrets and missing permission checks. What it learned as "normal" happens to be insecure.
• It only sees the local picture. When generating a snippet, it can't see your permission system, secret management, or security policy. To get the feature running first, it defaults to writing the key into the code.
• It aims for "it runs," not "it's safe." Security is an implicit quality requirement. Unless your prompt demands it explicitly, it won't add it.

The finer mechanics live in Common Flaws in AI Code. One more belief to add here: don't ask "why does AI keep writing insecure code"—ask yourself why you aren't reviewing. Faster tools don't mean higher quality; the security line was always a human's to hold. Before handing a job to AI, judge whether it deserves it—see What to Hand to AI.