SQL injection was discussed publicly in the late 1990s, including in a 1998 Phrack article by Jeff Forristal, who wrote as rain.forest.puppy. It has appeared in breaches ever since, including a mass campaign against the MOVEit file transfer service in 2023. Parameterised queries remain the main defence.
A timeline
From the Wikipedia article on SQL injection:
- 1998. A Phrack Magazine article by Jeff Forristal helps start public discussion.
- 2002. Guess.com found vulnerable, exposing customer names and card data.
- 2009. Albert Gonzalez and two unnamed Russians charged over the theft of 130 million credit card numbers.
- 2012. A Yahoo! Voices breach exposed 450,000 logins stored in plain text, using a union based technique.
- 2015. TalkTalk breach tied to a legacy web portal. The article gives two figures for affected customers, about 400,000 in one section and 156,959 in another, so treat the count as uncertain.
- 2023. A mass SQL injection campaign targeted MOVEit.
Where it sat in OWASP rankings
OWASP listed SQL injection among top ten web vulnerabilities in 2007 and 2010, as the most critical in 2013, and under the broader Injection category, ranked third, in 2017. By 2021, the article says injection was detected in 94% of analysed applications.
Why it will not go away
The cause is mixing code and data: user input is pasted into a query string, and the database cannot tell which part was meant as instruction. Old code, quick scripts and legacy portals keep the pattern alive.
Defences that work
- Parameterised statements. Keep SQL code separate from user input, so input is treated as data.
- Allow list validation. Accept only explicitly defined input and reject everything else.
- Least privilege. Limit database accounts to the minimum permissions they need.
OWASP, per the article, calls string escaping frail compared to the others. And an ORM can still be vulnerable if it is used improperly, for example by building raw query fragments from input.
A practical order of work
First, find every place where input reaches a query. Second, switch those to parameters. Third, reduce database permissions so that a missed spot does less damage. Fourth, test with a scanner and with code review.
A short code review checklist
When you review code for injection, look for string building near database calls, especially concatenation with request data. Look for raw query helpers inside an ORM, for dynamic sort or column names, and for stored procedures that build SQL inside themselves. Check that the database account has only what it needs. Confirm that error messages do not reveal query text. Then test the suspicious spots with unusual input. Most injection bugs sit in a small number of places, so a focused hour can cover a lot of ground.
Quick check
What is the primary defence against SQL injection?
Parameterised statements, which keep SQL code separate from user input.
Does using an ORM guarantee safety?
No. An ORM that is used improperly can still be vulnerable.
Safeguard offers dependency scanning and policy gates for pull requests, with a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
