In February 2025, researchers behind the BaxBench benchmark ran 392 security-critical backend coding tasks through today's leading LLMs and found that 62% of the solutions from even the best-performing model were either functionally broken or exploitably insecure. That is not a fringe result. It sits alongside a 2021 Asleep at the Keyboard study of GitHub Copilot, a 2023 Stanford user study of 47 developers, and a growing pile of 2025 vendor scans, all pointing at the same two failure modes: SQL queries built with string concatenation instead of parameterization, and authentication code that hardcodes secrets, skips validation, or hashes passwords with MD5. This post walks through what the research actually says about AI-generated SQL injection and auth flaws, why the patterns keep recurring across models and vendors, and where they show up in real generated code. It closes with how Safeguard catches these specific patterns before they reach a production branch.
How often do AI coding assistants suggest SQL injection–prone queries?
Often enough that it shows up as a top-three category in every major study of AI-generated code. The 2021 "Asleep at the Keyboard?" paper from NYU and UC San Diego researchers (Pearce, Ahmad, Tan, Dolan-Gavitt, Karri) tested GitHub Copilot against MITRE's CWE Top 25 and found that roughly 40% of completions in security-relevant scenarios contained a vulnerable pattern, with injection flaws among the most common. Four years and several model generations later, BaxBench's February 2025 evaluation found the problem largely unchanged: across 14 backend frameworks and 6 languages, injection-class bugs remained one of the leading causes of exploit success against "correct" (functionally passing) generated code. Separately, aggregate open-source vulnerability tracking cited in Aikido's 2025 "State of SQL Injection" analysis shows SQL injection actually growing as a share of disclosed flaws, from 6.7% in 2024 to 7.2% in 2025 — the opposite direction you'd expect if code-generation tooling were quietly fixing the problem on its own.
Why do large language models keep generating string-concatenated SQL instead of parameterized queries?
Because that is what most of their training data looks like. Public tutorials, Stack Overflow answers, and bootcamp course repos are dense with "SELECT * FROM users WHERE id = " + userId style queries because they are short, they run, and they demo the point of the lesson without importing a driver-specific parameter binding API. An LLM completing a half-written execute() call is doing next-token prediction over that corpus, not reasoning about trust boundaries, so it reproduces whatever pattern is statistically dominant in similar contexts. This is why the failure is consistent across models and vendors rather than a quirk of one product: Copilot, ChatGPT-generated snippets, and open-weight coding models all default to concatenation unless the prompt or surrounding file already establishes a parameterized pattern for the model to continue. It also explains why the fix in practice isn't "use a better model" — even frontier models in the BaxBench 2025 results reverted to unsafe query construction on a meaningful share of tasks when the prompt didn't explicitly demand it, because nothing in an ordinary feature request ("add a search endpoint that filters orders by customer name") signals that injection is in scope.
What authentication mistakes show up most often in AI-generated code?
Four patterns account for nearly all of it: hardcoded secrets, weak password hashing, missing token validation, and default-permissive middleware. Security researchers at Invicti have documented that individual LLMs tend to reuse the same placeholder JWT signing secrets and default passwords across unrelated generated applications — meaning a secret an attacker extracts from one AI-scaffolded demo repo can plausibly work against a different app scaffolded by the same model. On the hashing side, it remains common for a freshly generated "add user registration" endpoint to hash passwords with MD5 or SHA-1 rather than bcrypt, scrypt, or Argon2, because those older functions are what dominate older tutorial code and require no additional library import to demonstrate quickly. JWT-handling code frequently defaults to the HS256 algorithm with a short, hardcoded signing key rather than pulling a secret from environment configuration, which makes the token trivially forgeable if the key is ever left at its generated default — a mistake that is easy to make when a developer copies a working demo straight into a staging environment without treating the auth layer as security-critical.
Did a controlled study actually prove AI assistants make developers write less secure code, or is this just anecdotal?
It was measured directly, not inferred. Stanford's Neil Perry, Megha Srivastava, Deepak Kumar, and Dan Boneh ran a 2023 user study (originally posted to arXiv in November 2022) with 47 participants split between those who had access to an AI coding assistant and those who did not, across security-relevant tasks in Python, JavaScript, and C. Participants with AI assistance wrote measurably less secure code, with the gap most pronounced on exactly the two categories this post is about: SQL injection and string/data encryption. The more striking finding wasn't just the vulnerability rate — it was that AI-assisted participants were more likely to describe their insecure code as secure than the control group was. In other words, the tool didn't just introduce the bug; it also suppressed the developer's own instinct to double-check the query or the hashing call, because the code "looked" complete and confident. That combination — more bugs, less scrutiny — is the specific mechanism that turns a training-data artifact into a shipped vulnerability.
How do these patterns actually reach production instead of getting caught in review?
They reach production because the code passes functional tests and looks idiomatic, so it clears the bar humans normally use to decide what deserves a closer look. BaxBench's 2025 results made this explicit: on average, roughly half of the solutions that passed functional correctness checks were still exploitable, meaning "the tests pass" and "the endpoint is safe" are increasingly uncorrelated signals for AI-authored backend code. A search-based query with a WHERE clause that filters correctly on every test input can still be one crafted string away from returning the entire table. Compounding this, generated auth code is often produced quickly as scaffolding — a login route, a JWT middleware stub — that a developer intends to "harden later," and later doesn't always arrive before a demo branch gets merged or a prototype gets pointed at real user data. GitGuardian- and Invicti-style secret-scanning research on AI-scaffolded repos has repeatedly found the exact placeholder secrets and default credentials models emit sitting untouched in committed code, which is the tell that "harden later" frequently means "never."
What should a team actually check before merging AI-generated data-access or auth code?
Every AI-suggested SQL statement should be traced back to confirm it uses parameter binding, not string formatting, and every auth route should be checked for a hardcoded secret, a non-constant-time comparison, or a hashing call that isn't bcrypt/Argon2/scrypt. In practice this means treating AI-completed diffs touching execute, query, raw(), JWT signing, password hashing, or session token generation as a distinct review category — not because the developer is careless, but because the studies above show the assistant itself is statistically biased toward the unsafe version of each of these calls. Static analysis tuned to these specific patterns (string-built queries reaching a DB driver call, hardcoded values reaching a JWT sign/verify function, weak digest algorithms reaching a password field) catches the large majority of cases without requiring a human to re-derive the vulnerability from scratch on every pull request.
How Safeguard Helps
Safeguard's software supply chain security platform is built to catch exactly this class of problem at the point code enters your repository, before it becomes a dependency other services trust. Our scanning pipeline flags AI-generated and human-written code alike for the concrete patterns covered above: string-concatenated or f-string-built SQL and NoSQL queries reaching a database call, hardcoded JWT signing keys and API secrets, weak or deprecated hashing algorithms in authentication paths, and missing parameterization in ORMs that still allow raw query escapes. Because these patterns repeat predictably across models — the same placeholder secrets, the same MD5 calls, the same concatenated WHERE clauses — Safeguard's detection rules are tuned specifically to how AI assistants generate insecure SQL and auth code, not just generic CWE signatures written for human-authored bugs. That means pull requests get flagged with the specific line and the specific fix — bind the parameter, source the secret from a vault, swap the hash function — before a reviewer has to spot it by eye, and before an AI-scaffolded prototype quietly becomes the auth layer of a production service.