Cursor injection happens when untrusted input can influence a database cursor, query iteration, or related control flow. Attackers abuse it to change which records are read, updated, or skipped, especially when applications concatenate input into database commands or trust cursor positions from the client. Defenders use parameterised queries, strict input handling, and least-privilege database accounts.
How Cursor Injection Happens
cursor injection starts when application input is allowed to shape a database cursor, query iterator, or the control flow that depends on it. The core failure is trust: user-controlled values affect which rows are fetched next, which records are updated, or whether items are skipped. That often appears in dynamic SQL, unsafe pagination logic, or APIs that accept cursor tokens from the client.
Because cursors are stateful, the weakness is not limited to classic injection into a single query string. An attacker may tamper with the cursor position, offset, sort key, or filter expression so the application follows an unintended path through the result set. The practical problem is that a small input flaw can change data access order, integrity, and business logic at the same time.
Two conditions usually make it exploitable: the application must treat cursor-related data as trustworthy, and the database layer must execute that trust without strong parameterisation or validation. NHIMG’s Web Application Attacks Guide is useful here because cursor injection sits in the same family as other injection patterns where attacker-controlled input alters backend behavior.
Where the Business Logic Breaks
Cursor injection is especially damaging when the cursor controls record selection, batch processing, or update order. In those cases, tampering may cause the application to process the wrong customer, repeat a transaction, omit rows from review, or expose records that should have remained hidden. The impact is often subtle because the system may still look functional while producing incorrect results.
It also appears when developers assume the cursor is only a navigation aid. If the cursor value is used to reconstruct a query or decide the next database action, it becomes part of the security boundary. That is why the issue is not just about “bad input” but about letting external state influence privileged database decisions.
For teams building or reviewing AI-assisted development flows, the AI Coding Agents Security Guide is a relevant companion because generated database code and cursor handling are often introduced quickly and without enough review of how untrusted values move through the query path.
What Defenders Should Verify First
The first check is whether any cursor, offset, continuation token, or query fragment from the client can influence database logic beyond simple pagination. If the value can alter filters, joins, ordering, or write targets, assume the application has an injection surface until proven otherwise. Review both the application code and the database access layer, because cursor injection is often introduced across layers rather than in one obvious function.
Defenders should also verify that database accounts used by the application have only the rights they need. Least privilege does not stop injection, but it can sharply reduce what an injected cursor can read or modify. In practice, that means separating read and write roles where possible and avoiding broad database credentials in application services.
The same review should confirm that cursor values are opaque, server-generated, and validated on receipt. If the client can forge or replay a cursor, then application logic may trust attacker-chosen state. NHIMG’s PocketOS database deletion incident illustrates the wider lesson that over-privileged backend access can turn a logic flaw into rapid data loss.
Risk and Threat Considerations
Cursor injection matters because it can quietly turn a navigation mechanism into an access-control bypass or data-integrity flaw. The attacker does not need to break the database itself; they only need to influence the application’s assumptions about what record comes next, what should be updated, or which rows are safe to reveal.
Failure mechanism: Untrusted cursor state is reused inside database commands or iteration logic, so the application executes attacker-shaped control flow instead of server-owned query behavior.
Impact: The result can be unauthorized reads, incorrect writes, skipped records, broken auditability, or downstream corruption of business processes that depend on ordered database operations.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while OWASP ASVS, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V8 — Authorization | Cursor tampering can alter what rows or actions are authorised. |
| V4 — API and Web Service | Client-supplied cursors are often passed through APIs that shape backend queries. | |
| Recommendation — Enforce server-side authorization on every cursor-driven data access. Validate and constrain cursor parameters before they reach database logic. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Least privilege limits what injected cursor-driven actions can read or change. |
| Recommendation — Restrict application database accounts to the minimum permissions needed. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | Cursor abuse can steer the app into functions or data actions the caller should not reach. |
| Recommendation — Check that cursor-controlled operations cannot invoke unauthorised functions. | ||
| CIS Controls v8 | CIS-5 — Account Management | Application and database account scope determines how much damage cursor abuse can do. |
| Recommendation — Limit service account privileges and remove unnecessary database access paths. | ||
Practitioner Guidance
What to verify: Treat every client-supplied cursor or continuation token as hostile until you can prove it is opaque, signed, and server-validated. If it affects query text, sorting, or row selection, review it as an injection risk rather than a pagination feature.
Decision rule: If the cursor can influence which records are touched, prioritize parameterisation and server-side state over client-controlled cursor reconstruction. If the application must accept cursor-like input, constrain it to a narrow, well-typed format and reject anything that can alter query structure.
Practitioner takeaway: Cursor injection is not just “bad pagination”, it is a trust-boundary failure, and the safest design is to keep cursor state server-owned, opaque, and unable to steer database logic.