SQL injection from string-built database queries
SQL injection happens when a database query is built by inserting user input directly into a string of SQL text, instead of passing it as a separate parameter. A crafted input can change what the query actually does.
#What goes wrong
Most apps built with an ORM like Prisma or Drizzle are safe by default, but raw query escape hatches, like a template-string query passed straight to a Postgres client, are sometimes used for a query the ORM can't express cleanly, and user input gets interpolated straight into the string.
#Why it matters
A successful SQL injection can let an attacker read every row in every table, including other users' data and password hashes, or delete the whole database outright. It remains one of the most damaging classes of bugs because a single vulnerable query can expose everything.
#How Heimdall checks for this
Heimdall looks for raw SQL execution and checks whether user-controlled values are interpolated directly into the query string rather than passed as bound parameters.
#How to fix it
Use your ORM's parameterized query methods instead of raw string interpolation. If a raw query is unavoidable, use the tagged-template form your database library provides, like Prisma's $queryRaw with a template literal instead of $queryRawUnsafe, so values are automatically parameterized rather than concatenated.
Frequently asked questions
Am I safe if I only use Prisma's normal query methods?
Does this apply to NoSQL databases like MongoDB?
How do I know if my query is parameterized?
Run this check on your own repo
Heimdall scans your GitHub repo for this and 29 other issues in under a minute.