SQL Injection via String Concatenation

SQL injection by string concatenation occurs when an application assembles a SQL statement by gluing user input directly into the query text. Because the database cannot distinguish intended query structure from injected input, an attacker who controls part of that string can rewrite the query — reading other users' data, bypassing authentication, modifying records, or in some configurations executing commands on the host.

Why It Happens

Concatenation is the obvious way to build a dynamic query: "SELECT * FROM users WHERE name = '" + name + "'". It reads naturally and works for benign input during testing. Developers may not realize that input like ' OR '1'='1 changes the query's meaning, or they trust that client-side validation or escaping is sufficient. Dynamic requirements — variable filters, sorting, or table names — push teams toward building SQL as text.

Why It Hurts

Injection is among the most damaging and most common web vulnerabilities. A crafted input can turn a login check into an always-true condition, dump entire tables via UNION SELECT, drop tables, or escalate to operating-system access through database features. Manual escaping is fragile: encoding rules differ by database and data type, and a single missed case reopens the hole. Once exploited, the impact is total — confidentiality, integrity, and availability all collapse.

Warning Signs

• Queries are built with +, string interpolation, or format strings containing variables.
• User input flows into a WHERE, ORDER BY, or LIMIT clause without binding.
• The codebase relies on a custom escapeString function for safety.
• Logs show unusual quotes, comments (--), or UNION in query parameters.

Better Alternatives

Use parameterized queries (prepared statements) everywhere: the query structure is fixed and sent separately from the data, so input can never change the query's meaning. Every mainstream driver and ORM supports bound parameters — prefer them over raw string building. ORMs and query builders that bind parameters by default eliminate most risk. For elements that cannot be parameterized (table or column names, sort direction), validate against a strict allowlist rather than inserting input. Layer in input validation as defense in depth, and run the database with least-privilege accounts so a successful injection is contained.

How to Refactor Out of It

1. Search for every place a query is built by concatenation or interpolation.
2. Convert each to a parameterized statement, passing user values as bound parameters.
3. Replace dynamic identifiers with allowlist lookups (map a user choice to a known-safe column name).
4. Remove custom escaping helpers once parameters are in place.
5. Grant the application database user only the privileges it needs; revoke DDL and admin rights.
6. Add static analysis and tests with malicious payloads to prevent regressions.