SQL injection is one of the oldest named vulnerabilities in software, old enough that plenty of people assume it's a solved problem from a different era. It still shows up in fast-built apps today, and I think part of why is that the name sounds more abstract and intimidating than what's actually happening underneath it.
What a database query normally looks like
Somewhere in your app's code, a request to look up a user probably gets built by taking something the visitor provided, a username, a search term, an ID, and inserting it into a question your database understands: find me the record where the name matches this. When that insertion happens safely, the database treats the visitor's input purely as data, a value to match against, nothing more.
What goes wrong when it's built the risky way
The risky version builds that database question by directly gluing the visitor's raw input into the middle of the query text itself, as if it were part of the instruction rather than a piece of data. If a visitor types something that looks like ordinary text, this works exactly as expected. If a visitor deliberately types something crafted to look like part of the query's own structure, phrases a database would normally treat as commands rather than data, the database can end up executing that structure instead of just searching for it as a plain value.
What that actually enables
Depending on exactly how the query was built, this can let someone bypass a login check entirely by crafting input that makes the underlying question always true regardless of the real password, pull back data from tables the query was never meant to touch, or in the worst cases, modify or delete data outright. None of it requires guessing a password or finding a leaked key. It requires the database treating something as an instruction that was only ever supposed to be a piece of data.
Why AI coding tools mostly avoid this, but not always
Most modern frameworks and the query patterns AI tools reach for by default use a safer method that keeps user input clearly separated from the query's structure, the database equivalent of filling in a form's blanks rather than letting someone hand-edit the form itself. This has made the classic version of this bug rarer than it used to be. It still shows up when a query gets built by directly combining strings together for something the standard safe pattern didn't obviously cover, a dynamic search feature, a custom sorting option, an edge case that got hand-built rather than following the framework's usual approach.
How to actually check your own app
- Search your codebase for any place a database query gets built by directly combining or concatenating strings, rather than using your framework's standard parameterized query method.
- Pay particular attention to search bars, sorting options, and filters, the features most likely to have been hand-built outside the default safe pattern.
- If you find a spot built this way, ask your AI coding tool directly to rewrite it using a parameterized query instead, which is a well-documented, standard fix it can apply reliably once asked.
This is one of the few bugs on this blog where the underlying tools have genuinely gotten better at avoiding it by default. It's not gone, though, and it's worth one deliberate check rather than assuming a decades-old, well-known problem couldn't possibly still be sitting in a fast-built app today.