SQL Injection
SQL injection is a code injection attack where malicious SQL statements are inserted into application queries through unsanitized user input, allowing attackers to read, modify, or delete database contents.
Understanding SQL Injection
SQL injection occurs when user-supplied data is concatenated directly into SQL query strings without parameterization or escaping. The attacker crafts input that breaks out of the intended query context and executes arbitrary SQL commands. For example, entering ' OR 1=1 -- into a login field could bypass authentication by making the WHERE clause always evaluate to true.
There are several variants. Classic (in-band) SQL injection returns data directly in the application response. Blind SQL injection infers information through boolean conditions or time delays when the application does not display query results. Out-of-band SQL injection exfiltrates data through DNS lookups or HTTP requests initiated by the database server itself.
The fundamental fix is parameterized queries (prepared statements), which separate SQL code from data. When using parameterized queries, user input is always treated as a literal value, never as executable SQL. ORMs like Prisma, Drizzle, and Sequelize use parameterized queries by default, but developers can still introduce SQL injection through raw query methods.
Beyond parameterized queries, defense in depth includes input validation, least-privilege database accounts, and web application firewalls. However, none of these should be considered a replacement for parameterization — they are supplementary layers.
Why This Matters for Vibe-Coded Apps
AI code generators sometimes produce raw SQL queries with string interpolation, especially when the prompt asks for complex queries that the AI cannot easily express through an ORM. This is the most direct path to SQL injection in vibe-coded apps. Even when using an ORM, AI-generated code may use raw query escape hatches like Prisma's $queryRawUnsafe or Drizzle's sql.raw() with user input concatenated in.
Always verify that any database queries in AI-generated code use parameterized queries or ORM methods that handle parameterization automatically. Search your codebase for raw query methods and check whether user input flows into them. Supabase's client library uses parameterized queries for its query builder, but the rpc() function for custom PostgreSQL functions can still be vulnerable if the function itself concatenates inputs.
Real-World Examples
Heartland Payment Systems Breach (2008)
SQL injection was the entry point for one of the largest data breaches in history, compromising 134 million credit card numbers from the payment processor. The attackers used SQL injection to install sniffing software on the company's servers.
Sony Pictures Hack (2011)
The LulzSec hacking group used a simple SQL injection to extract unencrypted personal data of over one million Sony Pictures users, including passwords, email addresses, and home addresses.
TalkTalk Data Breach (2015)
A teenager used SQL injection to access the personal data of 157,000 TalkTalk customers, including bank account details. The attack cost the company 77 million pounds and led to a record 400,000 pound fine from the ICO.
Frequently Asked Questions
Does using an ORM prevent SQL injection?
ORMs prevent SQL injection when you use their standard query builder methods, which generate parameterized queries behind the scenes. However, every major ORM provides raw query methods (Prisma's $queryRawUnsafe, Sequelize's query(), Drizzle's sql.raw()) that bypass this protection. If you concatenate user input into raw queries, you are vulnerable regardless of using an ORM. Always use the parameterized version of raw queries when they are necessary.
Can SQL injection affect NoSQL databases?
Yes, NoSQL databases like MongoDB have their own injection variant called NoSQL injection. Instead of SQL syntax, attackers inject query operators (like $gt, $ne, $regex) through JSON input to manipulate queries. For example, passing {"$ne": ""} as a password field could match any non-empty password. The defense is similar: validate and sanitize input, and use the database driver's built-in parameterization.
Is SQL injection still common in 2025?
SQL injection consistently ranks in the OWASP Top 10 and remains one of the most exploited vulnerability classes. While modern frameworks make it harder to introduce accidentally, it still appears in legacy code, raw query usage, stored procedures with dynamic SQL, and applications built without security knowledge. Automated scanners make it trivial to discover these flaws at scale.
What is the worst-case impact of SQL injection?
The worst case is complete server compromise. Depending on database permissions, an attacker can read all data, modify or delete records, create admin accounts, execute operating system commands (via xp_cmdshell in MSSQL or COPY in PostgreSQL), and read files from the server filesystem. This makes SQL injection one of the most severe vulnerability classes when database accounts have excessive privileges.
Is Your App Protected?
VAS automatically scans for vulnerabilities related to sql injection and provides detailed remediation guidance. Our scanner targets issues common in AI-generated applications.
Scans from $5, results in minutes. Get actionable fixes tailored to your stack.
Get Starter Scan