SQL Injection via Parameter Names

How Parameter Names Become a SQL Injection Surface

Parameter names are usually treated as metadata, but some applications feed them into dynamic SQL builders, query templates, or sorting and filtering logic. When that happens, the name itself becomes part of the statement structure, not just the data payload, and attacker control over the parameter key can influence how the database interprets the query.

This is especially dangerous because developers often focus on sanitising parameter values and overlook names, aliases, and field identifiers. The result is a class of injection that can sit in control-flow code, ORM helpers, custom filters, or API-to-database translation layers, where it is easier to miss in review.

Why This Injection Path Is Dangerous

SQL injection via parameter names can expose data, modify records, or bypass application logic if the application concatenates the name into a query without strict allowlisting. The risk is not limited to direct SELECT statements, because malformed names can also affect ORDER BY clauses, column selection, update targets, or nested query fragments.

The danger increases when the application also runs with broad database privileges. In that case, a successful injection can move from a single bad query to a wider compromise of confidentiality and integrity. NHIMG’s SQL Injection Prevention Guide and OWASP Top 10 A05 Guide both reinforce that the core defence is to keep untrusted input out of SQL structure.

Where This Pattern Usually Appears

This issue often appears in code that turns request keys into column names, filter expressions, or ORM query fragments. It can show up in frameworks that accept dynamic field names, in ad hoc report builders, in generic search endpoints, or in libraries that map HTTP parameters directly into database clauses.

ORMs do not eliminate the risk when developers step outside parameter binding and start building raw fragments. The most error-prone cases are dynamic identifiers, raw query helpers, and convenience abstractions that make it easy to confuse user input with trusted schema metadata. For a broader view of those failure modes, ORM Security Guide is the most direct internal reference.

Defensive Design and Validation Boundaries

The safest approach is to treat parameter names as untrusted input and map them to a fixed allowlist of permitted columns, operators, or sort fields. The application should never pass a raw request key into SQL generation, even if the value portion is already parameterised.

Defence also depends on separating concerns: request parsing should not decide schema structure, and database access code should not accept arbitrary identifiers from upstream layers. Database Security Guide is useful here because it ties injection prevention to database hardening, privilege boundaries, and monitoring rather than treating it as a code-only issue.

Detection and Post-Exposure Review

Because this technique may be triggered by unusual parameter keys rather than unusual values, detection should include failed queries, unexpected column references, syntax errors, and spikes in 4xx or database error responses. Query logs, application logs, and database audit trails are all relevant when tracing whether a malformed parameter name was accepted and executed.

After suspected exploitation, teams should review which statements ran, what data may have been read or changed, and whether the database account had permissions beyond the application’s normal needs. If the incident reached persistence or data access, Database Breach Response Playbook provides a practical recovery lens, and the OWASP Top 10 remains the baseline external reference for injection risk.

Related resources from NHI Mgmt Group

• How do attackers use SQL injection through SOAP parameter tampering?
• How can security teams detect SQL injection through SOAP parameter tampering?
• What mitigations reduce the risk of SQL Injection through SOAP parameter tampering?
• SQL Injection through SOAP Parameter Tampering