Data Injection vs SQL Injection: the difference that changes the fix

Was I hacked?

The label alone cannot answer that question. “SQL injection” tells you which interpreter may have been influenced. “Data injection” may refer to SQL, a shell, LDAP, NoSQL, a template, a log or another downstream parser. Compromise requires evidence that an untrusted value reached a vulnerable sink and produced an unauthorised effect.

If the suspected sink is SQL, preserve database audit events, application request IDs, the service account, query timing and returned record counts. If the suspected sink is a command runner, collect process creation, parent-child relationships, file changes and outbound connections. Using the SQL playbook for a shell problem is like bringing a very good umbrella to a server-room fire.

The short answer

SQL injection is a specific type of data injection. Data injection is the larger class.

In set notation:

SQL injection ⊂ data injection

Every SQL-injection flaw crosses a data/instruction boundary. Not every data-injection flaw involves SQL.

Comparison at a glance

The distinction matters because controls are contextual. SQL parameters cannot protect an LDAP filter, and escaping shell metacharacters does not make a NoSQL query object safe.

Same input, different interpreter

Consider a search value submitted as:

O'Brien

That is perfectly ordinary data. Its apostrophe becomes dangerous only if an application places it into a language where the apostrophe closes a string and fails to preserve the data boundary.

In SQL, this is unsafe:

const sql = "SELECT id FROM customers WHERE surname = '" + surname + "'";

The application has asked the SQL parser to decide where data ends. The safe version makes that decision before the SQL parser sees the value:

const result = await pool.query(
  'SELECT id FROM customers WHERE surname = $1',
  [surname]
);

In LDAP, the relevant characters and encoding rules are different. A filter such as this is unsafe:

String filter = "(&(uid=" + userInput + ")(objectClass=person))";

The safer JNDI form uses a parameterised filter:

String filter = "(&(uid={0})(objectClass=person))";
NamingEnumeration<SearchResult> results = ctx.search(
    "ou=users,dc=example,dc=test",
    filter,
    new Object[] { userInput },
    controls
);

OWASP’s LDAP Injection Prevention Cheat Sheet also distinguishes LDAP search-filter escaping from distinguished-name escaping. “We escaped it” is incomplete until someone asks, “for which grammar and which position?”

SQL injection: what the database interprets

SQL injection usually appears where code dynamically constructs a statement:

# Unsafe
sql = f"SELECT id, total FROM invoices WHERE account_id = {account_id}"
cursor.execute(sql)

The safe Python DB-API pattern binds the value:

cursor.execute(
    "SELECT id, total FROM invoices WHERE account_id = %s",
    (account_id,)
)

Placeholder syntax varies by driver. Copy the driver’s documented form rather than translating punctuation by intuition.

Prepared statements protect values. They do not correct missing authorisation. A perfectly parameterised query that accepts another customer’s invoice ID can still be broken access control.

They also do not normally bind identifiers. For a sort option, map a user-facing choice to code-owned SQL:

SORTS = {
    "newest": "created_at DESC",
    "oldest": "created_at ASC",
}
order_by = SORTS.get(request.args.get("sort"), SORTS["newest"])
cursor.execute(f"SELECT id, title FROM posts ORDER BY {order_by} LIMIT %s", (25,))

The allowlist contains complete known-safe fragments. It is not a denylist of exciting punctuation.

Command injection: what the shell interprets

This code creates a shell command from a filename:

subprocess.run(f"file {uploaded_name}", shell=True)

The safer design uses a library. If the utility is required, pass a fixed program and separate arguments without a shell:

from pathlib import Path
import subprocess

upload_root = Path("/srv/app/uploads").resolve()
candidate = (upload_root / uploaded_name).resolve()
if upload_root not in candidate.parents:
    raise ValueError("Invalid upload path")

subprocess.run(
    ["/usr/bin/file", "--brief", "--", str(candidate)],
    shell=False,
    check=True,
    timeout=5,
)

This is data injection, but it is not SQL injection. Database WAF signatures and SQL error monitoring will not repair or reliably detect it. Endpoint process telemetry is far more valuable after execution.

NoSQL injection: structure can be hostile too

Applications sometimes treat parsed JSON as inherently safe because there are no quote marks to concatenate. The client can still control query structure:

// Unsafe: req.body may contain operators, not just values.
const user = await users.findOne(req.body);

Build a new object from validated primitives:

const email = String(req.body.email ?? '').trim().toLowerCase();
if (!/^[^@\s]+@[^@\s]+\.[^@\s]+$/.test(email) || email.length > 254) {
  return res.status(400).json({ error: 'Invalid email' });
}
const user = await users.findOne({ email });

Do not accept raw query operators unless the endpoint explicitly needs them and validates each allowed operator. The OWASP NoSQL Security Cheat Sheet recommends constructing driver query objects and preventing client-controlled operators.

Detection differences

SQL injection may produce:

• database syntax errors;
• unusual statement shapes or query latency;
• abnormal row counts and broad exports;
• web requests containing SQL-specific tokens;
• a sequence of probes followed by a successful database action.

Other injection families produce different evidence:

• a web worker spawning cmd.exe, PowerShell, sh or a utility;
• LDAP searches returning an implausibly broad set;
• template compilation errors or unexpected template expressions;
• forged lines or broken structure in logs;
• NoSQL operators in a route that should accept plain strings.

A signature at the HTTP edge is a clue. It is not proof, because data may arrive through a queue, an import or a stored value. Conversely, a harmless apostrophe may match a poor signature. Detection should connect the source request to the sink and its effect.

Prevention differences

Use this decision sequence:

1. Can the interpreter be removed? Prefer a library over a shell command and a fixed template over runtime template compilation.
2. Does the API separate structure and values? Use SQL parameters, safe query builders and argument arrays.
3. Is any structure genuinely dynamic? Map a finite business choice to a code-owned fragment.
4. Does the grammar require contextual encoding? Use a maintained encoder for that exact context, such as LDAP filter versus LDAP DN.
5. What can the runtime identity do? Restrict database, filesystem, network and operating-system privileges.
6. Can a test prove separation? Assert the executed statement and parameter collection, not merely the HTTP status.

A safe regression exercise

Run tests only against a local or explicitly authorised staging system. Use representative valid data and a benign syntax-shaped value. The expected result is normal validation or a normal zero-result response, never a database error or a widened result set:

curl -i --get 'https://staging.example.test/search' \
  --data-urlencode "q=O'Brien"

Then inspect the application test double or database instrumentation to confirm the value was bound separately. A 200 response alone does not reveal how the query was constructed.

Which article should you read next?

• Start broad with What is Data Injection?.
• Follow the data path in How Data Injection Attacks Work.
• Copy safer patterns from Data Injection Examples.
• Build controls with Data Injection Prevention.
• Investigate telemetry with How to Detect Data Injection.

References

• MITRE CWE-74: Injection
• MITRE CWE-89: SQL Injection
• OWASP SQL Injection Prevention Cheat Sheet
• OWASP Query Parameterization Cheat Sheet
• OWASP OS Command Injection Defense Cheat Sheet
• OWASP LDAP Injection Prevention Cheat Sheet
• OWASP NoSQL Security Cheat Sheet

Reviewed 5 September 2026.