Kotlin SQL injection exposes how raw queries break access control

At a glance

What this is: This is a Kotlin SQL injection guide showing that raw string-built queries can let attacker input change database logic and bypass access controls.

Why it matters: It matters because application teams, IAM leads, and security engineers need to treat database query construction as an authorization boundary, not just a coding style choice.

Context

SQL injection is a query-construction flaw, not just a database problem. It appears when applications place untrusted input directly into executable SQL, allowing the attacker to change what the database returns or modifies. In identity and access terms, that means the application can accidentally hand out data or write access that was never authorised by the business rule.

In Kotlin applications, this risk becomes visible when raw queries or native SQL paths are used inside ORMs and server handlers. The article's examples show the same governance failure in different forms: user input reaches the query engine before validation or parameter binding. That is a typical application security pattern, and it becomes especially relevant when the data being queried is tied to user-specific access decisions.

Key questions

Q: What breaks when Kotlin applications build SQL with raw user input?

A: The code-data boundary breaks, which means the database can execute attacker-controlled logic instead of the intended lookup or update. In practice, that can expand a single-record request into table-wide disclosure, mass updates, or destructive operations. The failure is not just vulnerability to attack, but loss of control over what the application is authorised to do.

Q: Why do prepared statements reduce SQL injection risk so effectively?

A: Prepared statements separate the SQL structure from the data values, so the database parses the query before it sees user input. That makes injected operators, comments, and extra clauses harmless as literals. The control is effective because it removes the attacker’s ability to change the executable statement, which validation alone cannot guarantee.

Q: What do teams get wrong about ORM safety and native SQL?

A: They assume the ORM protects every database call, even when developers drop into native SQL or manual connection handling. The risk returns the moment a query is assembled as text. Teams should therefore review low-level SQL paths separately and require the same parameter-binding standard there as in handwritten code.

Q: How should security teams test whether query access is actually controlled?

A: Test whether attacker-controlled values can change the scope of returned or modified records, not just whether the code compiles or passes unit tests. A secure endpoint should still behave correctly when inputs contain quotes, operators, or malformed identifiers. If those inputs alter the query result, the access boundary is not under control.

Technical breakdown

Why string interpolation turns SQL into executable attacker input

Raw queries become dangerous when developers concatenate user-supplied values into SQL text. At that point, the database no longer sees a fixed statement with separate data fields. It sees one executable string, so an input like OR 1=1 can change a WHERE clause into a broad data disclosure condition. In Kotlin, that risk appears in URL parameters, form fields, and application variables that are inserted directly into query strings. The core problem is not SQL itself, but the collapse of the boundary between code and data.

Practical implication: keep untrusted values out of query text and force them into bind parameters.

How prepared statements preserve the code-data boundary

PreparedStatement changes the execution model by compiling the SQL shape first and binding values separately. That means the query structure is fixed before any user input is applied, so injected operators and clauses are treated as literal data rather than instructions. This is the central control that neutralises many injection paths. In access-control terms, it also protects application logic that depends on record identifiers, because the database only evaluates the intended predicate and not attacker-supplied control flow.

Practical implication: use parameter binding for every user-controlled field, including identifiers and update values.

Why ORM native SQL paths reintroduce injection risk

ORM frameworks can reduce risk when developers stay inside their parameterised abstractions, but native SQL escape hatches reopen the same vulnerability class. Once code calls a low-level connection and builds SQL manually, the ORM no longer protects the statement boundary. That is why a framework is not a control by itself. The control is the specific query construction pattern used inside the framework. Teams often assume the ORM equals safety, but raw SQL inside an ORM is functionally the same as handwritten vulnerable SQL.

Practical implication: inventory native SQL usage inside ORM code and treat it as a separate review path.

Threat narrative

Attacker objective: The attacker aims to bypass application access restrictions by turning legitimate database queries into unauthorised read, write, or destruction actions.

1. Entry occurs when application-supplied values are inserted directly into a Kotlin SQL statement through raw string construction or native SQL.
2. Credential access is not the primary stage here, but the attacker abuses query logic to expand read or write scope beyond the intended record.
3. Impact follows when the altered query exposes private data, overwrites records, or drops tables, producing unauthorised disclosure or destructive loss.

Breaches seen in the wild

• Firebase misconfiguration exposure 2024: Missing Firebase security rules on 916 websites exposed 125 million user records and 19.87 million plaintext passwords; a quarter were fixed.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

SQL injection is an access-control failure disguised as a query bug. Once application input can alter the executable SQL path, the database is no longer enforcing the intended authorisation boundary. That matters to identity practitioners because application logic often decides which record a user should see, and injection lets the attacker change that decision at the point of execution. Practitioners should treat query construction as part of the authorisation model, not only as input handling.

Prepared statements are the real control plane for database safety. They preserve the code-data split that raw string concatenation destroys, which is why they remain the decisive preventive measure. Validation still matters, but it is secondary because validation alone does not reliably stop every injection shape. Teams that rely on ORM branding rather than bind parameters are relying on an assumption, not a control.

ORM adoption does not eliminate developer-owned risk. Native SQL escape hatches shift the burden back to the application team, and that is where many injection paths reappear. The governance lesson is simple: safe defaults must be verified at every data access layer, especially where developers can bypass the framework. The practitioner conclusion is to audit the unsafe exceptions, not just the standard path.

Raw query exposure creates a governance gap between identity intent and database effect. The application may intend to show one user one row, but concatenated SQL lets input redefine the scope of access. That is why this issue belongs in application security reviews, IAM-adjacent access governance, and secure coding standards alike. The practical takeaway is to govern query construction with the same discipline used for privilege boundaries.

From our research library:

• The average time to mitigate a leaked secret is 36 hours, highlighting the operational burden of manual remediation processes, according to the 2024 State of Secrets Management Survey.
• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to the State of Secrets in AppSec.

What this signals

Query construction is now an authorisation issue, not only a secure-coding issue. Teams that map user input directly into SQL are allowing application logic to decide who can see or change which records, and that decision can be overwritten by attacker-controlled syntax. The governance response is to review database access patterns with the same seriousness as privilege design, because the boundary failure happens before the database can enforce intent.

Prepared statements and strict parsing should be the default, not the exception. The operational lesson for Kotlin teams is to remove every path that lets raw user input become executable SQL, including ORM escape hatches and ad hoc admin code. That shift matters because injection prevention has to happen at issuance time, when the query is built, not after the database has already interpreted it.

For practitioners

• Enforce parameter binding everywhere Replace string-built SQL with prepared statements for all user-controlled values, including IDs, emails, and update fields, so the database never interprets input as code.
• Audit ORM escape hatches Inventory native SQL calls, connection-level statement execution, and dynamic query builders in Kotlin services, then require security review for every exception.
• Validate type and shape before query execution Use strict parsing, expected-length checks, and type conversion such as numeric coercion for identifiers before any database call is made.
• Treat query construction as an access-control control Review endpoints that map user input to record lookups, updates, or deletes as part of application authorization testing, not only injection scanning.

Key takeaways

• Kotlin SQL injection shows that raw query construction can turn a normal lookup into unauthorised disclosure, data tampering, or destructive deletion.
• The decisive control is keeping user input out of executable SQL by binding values separately and validating types before any query runs.
• ORMs do not remove the risk if developers can fall back to native SQL or manual statement execution.

Key terms

• SQL Injection: SQL injection is a flaw where untrusted input is interpreted as part of a database query. In practice, it lets an attacker read, change, or delete data by manipulating the application’s request handling rather than by logging in with valid credentials.
• Prepared Statement: A database query pattern that separates code from data so user input cannot change the structure of the statement. It is one of the most reliable ways to prevent injection because the database treats parameters as values, not executable query logic.
• Raw Query: A raw query is SQL assembled directly as text, often with string interpolation or concatenation. It is flexible, but that flexibility creates risk because any untrusted value inserted into the string can become part of the executable statement rather than a safe parameter.
• Input Validation: Input validation is the process of checking that data matches the type, format, and range an application expects before it is used. In database-backed applications, validation reduces malformed input risk, but it only becomes a security control when paired with safe query parameterisation.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore nhimg.org for resources that connect identity governance to the broader security disciplines your programme depends on.