Security5 min read
SQL Injection Still Happens in 2026 — Here's How
Every modern ORM protects against naive SQL injection by default. The real injection findings I still see are in the places ORMs don't cover.
Tanjil Ahmed
Lead Software Engineer · Notionhive
SQL injection is treated as a solved problem, and mostly it is — no modern engineer is concatenating raw request input into a query string on purpose. The findings that still show up in real audits happen at the edges the ORM doesn't automatically cover.
- Raw query fragments for 'complex sorting' or dynamic `ORDER BY` columns, built from unvalidated user input.
- Dynamic table or column names built from request data — parameter binding doesn't protect identifiers, only values.
- Third-party reporting or export tools that accept a 'custom query' field meant for admins, exposed to a broader user base than intended.
- Search functionality using raw LIKE queries built with string concatenation instead of the ORM's query builder.
The pattern across all of these is the same: a developer reached past the ORM's safe query builder for a feature it didn't obviously support, and built the query by hand under time pressure. That's still exactly how SQL injection happens today.
SQL injection didn't disappear. It moved to the exact places developers reach past their ORM to get something done quickly.
