SQL Injection in 2024: Modern Vectors

PostgreSQL jsonb, MySQL JSON_EXTRACT and SQL Server OPENJSON often accept user input as part of the path expression. Developers parameterize the value but concatenate the path. The result is a fully exploitable injection that scanners almost never catch because the response shape looks normal.

The payload is stored cleanly during one request and concatenated unsafely in a later background job, report export, or admin panel query. Detecting this requires tracking data flow across multiple requests — manual testing can follow them; automated scanners rarely do.

Most modern frameworks default to parameterized queries. But every ORM has an escape hatch — Sequelize literal, Hibernate createNativeQuery, Django extra(), SQLAlchemy text(). Developers reach for these when they need a feature the ORM does not support, and the safety guarantees evaporate.

Sort columns and direction often come from query string parameters. Whitelisting is rare. A typical exploitable pattern looks like:

ORDER BY ${user_input} ASC

Time-based blind SQLi via the ORDER BY clause is detectable with a few targeted payloads. We cover detection in detail in blind SQLi detection.

Parameterize every value, allowlist every identifier (column, table, sort direction), and ban concatenation into raw queries via a lint rule. For deeper coverage, our source code review service maps every database call against this checklist.