The Most Common Security Mistakes in AI-Generated Code

Code written with an AI coding assistant is not inherently less secure than code written by hand. The problem is not the code's origin, it is the speed and the missing feedback loop. When you write something yourself, slowly, you have time to notice "wait, should this be public?" When an assistant generates a whole feature in one pass and it just works, that question often never gets asked. Here are the specific mistakes that show up again and again.

1. Hardcoded secrets and API keys

An AI assistant reaching for a working example will often paste in a real-looking pattern: an API key assigned directly in a config file, a database URL with credentials embedded in it, a webhook secret sitting in plain text. It works locally, it gets committed, and now it is in your git history forever, even if you delete it in the next commit. Gitleaks-class tools scan for exactly this pattern and catch it before it ships.

2. Open databases (see the RLS post)

Covered in detail in our Supabase RLS post, but it is common enough to repeat here: a working app and a protected database are two different things, and only checking the first one is the single most common gap.

3. Known-vulnerable dependencies

An AI assistant will happily install whatever package solves the immediate problem, often pinned loosely or not pinned at all. Some of those packages have real, published vulnerabilities (tracked in the OSV.dev advisory database) that a quick dependency scan catches in seconds, but that nobody checks unless something specifically prompts them to.

4. Missing or incomplete access checks

"Can this user see this page" and "can this user's account actually access this specific record" are different questions. It is easy to build a feature that correctly gates the page (you have to be logged in) while leaving the underlying data fetch ungated (any logged-in user's ID works, not just your own). This is the class of bug generally called an IDOR, and it is one of the most common mistakes in fast-built apps regardless of who or what wrote the code.

5. Trusting AI-written code the same way you'd trust a senior engineer's review

The code compiling and the feature working is real signal, but it is not the same signal as a second set of eyes checking for exactly the mistakes above. That is the actual gap Riskline exists to close: the same deterministic tools professional security teams use (Semgrep, Gitleaks, OSV-Scanner, plus native Supabase/Firestore checks), run automatically, explained in plain English, with a fix you can hand straight back to your AI coding tool.

A free scan checks for all five of these in under a minute.