Securityintermediate12 min read

SQL Injection: How It Works and How to Prevent It

Understand SQL injection attacks with concrete examples, learn why parameterized queries are the only real fix, and explore defense-in-depth strategies for secure database access.

What is SQL Injection?

SQL injection (SQLi) is an attack where malicious SQL code is inserted into a query through user-supplied input. It consistently ranks in the OWASP Top 10 most critical web application security risks and has caused some of the largest data breaches in history.

Impact ranges from: - Data exfiltration — reading any data in the database, including users, passwords, payment info - Authentication bypass — logging in without valid credentials - Data modification — updating or deleting records - Full server compromise — on some database configurations, executing OS commands

Classic SQL Injection Examples

Consider a login query built by string concatenation:

-- Vulnerable query (NEVER do this)
const query = `SELECT * FROM users WHERE email = '${email}' AND password = '${password}'`;

-- Attacker enters email:    admin@example.com' --
-- Attacker enters password: anything

-- The resulting SQL:
SELECT * FROM users WHERE email = 'admin@example.com' --' AND password = 'anything'
-- Everything after -- is a comment! The password check is skipped.

-- UNION-based extraction: attacker inputs:
' UNION SELECT username, password, null FROM users --

-- Destructive input:
'; DROP TABLE users; --

The Only Real Fix: Parameterized Queries

Parameterized queries (also called prepared statements) keep SQL code and data structurally separate. The database driver sends the query template and the values independently — user input is never interpreted as SQL syntax.

// Node.js — pg (PostgreSQL)
const { rows } = await pool.query(
  'SELECT * FROM users WHERE email = $1 AND password_hash = $2',
  [email, passwordHash]
);

# Python — psycopg2
cursor.execute(
  'SELECT * FROM users WHERE email = %s',
  (email,)  # Note the trailing comma — must be a tuple
)

// Java — JDBC
PreparedStatement stmt = conn.prepareStatement(
  "SELECT * FROM users WHERE email = ?"
);
stmt.setString(1, email);
ResultSet rs = stmt.executeQuery();

ORMs and Query Builders

Object-relational mappers like Prisma, SQLAlchemy, Hibernate, and ActiveRecord use parameterized queries internally by default. Their high-level APIs make injection virtually impossible for standard operations:

```javascript // Prisma — safe by default const user = await prisma.user.findFirst({ where: { email } }); ```

Danger zone: raw query methods bypass this protection and re-introduce injection risk:

Prisma: `prisma.$queryRaw` and `prisma.$executeRaw`
SQLAlchemy: `session.execute(text(f'... {value} ...'))`
ActiveRecord: `User.where("email = '#{email}'")`

When you must use raw queries, use the ORM's parameterized raw query API:

```javascript // Prisma raw — parameterized with Prisma.sql const users = await prisma.$queryRaw`SELECT * FROM users WHERE email = ${email}`; ```

Defense in Depth

Parameterized queries are necessary but not sufficient on their own. Layer these additional controls:

Allowlist input validation — reject input that doesn't match expected patterns before it reaches the database
Least-privilege database users — your app user should only have SELECT/INSERT/UPDATE on the tables it needs; never connect as a superuser
Web Application Firewall (WAF) — catches known attack patterns as a safety net
Suppress database error messages — never expose raw database errors to users; log them server-side only. Error messages reveal table names, column names, and database version.
Stored procedures — can limit the SQL operations an app can perform to a predefined set

String Escaping as a Last Resort

String escaping — converting `'` to `''` or `\'` before interpolation — is not equivalent to parameterized queries and should only be used when no other option exists (e.g., column or table names in dynamic queries, which cannot be parameterized).

Escaping is error-prone: it's encoding-dependent, easy to forget, and historically has had bypass vulnerabilities. The DevForge SQL Escape tool correctly escapes special characters and is useful for quick testing or one-off data migrations, but production code should always use parameterized queries.

The DevForge SQL Formatter helps you review and understand complex query structure before running it.

Try it on DevForge

Free online tools related to this tutorial — no signup required.

SQL\

SQL Escape

Escape SQL strings

SQL

SQL Formatter

Format SQL queries