Authorization Bypass Through User-Controlled SQL Primary Key

How This Flaw Works

This weakness appears when an application treats a user-supplied primary key as proof of authority. If the server uses that identifier to load or update a record without checking ownership or access rights, an attacker can swap the key and reach another user’s object.

The issue is not the database primary key itself, but the trust boundary around it. A record identifier can be stable, predictable, or easy to guess, which makes it a poor substitute for server-side object-level authorisation.

Why It Becomes an Authorization Problem

At a technical level, the flaw is a form of object-level access control failure. The application may authenticate the user correctly, yet still allow that user to act on records they do not own because the record lookup happens before the authorisation decision.

This is why defences focus on the server, not the client. The application must verify that the current subject is allowed to access the specific object, rather than assuming that a presented identifier is legitimate. Authorisation Models Guide is useful background when teams need to compare policy patterns for enforcing that decision.

Where applications expose records through APIs, the same weakness often shows up as broken object-level authorisation. The control failure is identical: the request reaches a valid object, but the application does not bind access to the right subject and resource combination.

Where Attackers Abuse It

Attackers usually look for predictable identifiers in URLs, JSON payloads, forms, GraphQL variables, or hidden fields. Once one valid key is known, they test adjacent values or replace the object reference in a request to see whether the application returns data or performs the requested change.

Because the request is otherwise well-formed, simple authentication checks, session validation, and perimeter controls may all succeed. That makes the flaw especially useful for horizontal privilege escalation, data theft, and unwanted record modification.

In API-heavy systems, this pattern is often easier to exploit than traditional injection flaws because the attacker does not need to break the transport or the database, only the authorisation logic surrounding the object reference.

What Defenders Should Enforce

Design the application so the server derives the accessible object set from the user’s permissions, not from a raw client-supplied key. When practical, expose opaque references, but treat them as usability aids, not as security controls.

Every fetch, update, delete, and export path should perform an object-level check against the caller’s rights. That includes secondary code paths such as bulk actions, search endpoints, background jobs, and administrative views. For a broader control lens, IAM and IGA Basics helps place object checks inside the wider access-governance model.

Defenders should also review how identifiers are exposed across different layers, because a secure front end can still be undermined by a weaker API or service endpoint. The safest pattern is consistent server-side mediation of object access everywhere the record can be reached.

Risk and Threat Considerations

This flaw can expose sensitive records at scale when object identifiers are enumerable, reused, or exposed across multiple interfaces. It often creates quiet data loss because requests look legitimate, which makes detection harder than with obvious exploitation attempts.

Failure mechanism: The application accepts a user-controlled primary key and fails to bind the request to the caller’s permissions before returning or changing the object.

Impact: Attackers can read, modify, or delete other users’ records, leading to confidentiality breaches, integrity loss, and possible account or workflow abuse.

Practitioner Guidance

What to watch for: Investigate any endpoint that accepts a record identifier from the client and returns data without a clearly defined ownership or entitlement check. Pay particular attention to update and export functions, because they often have the highest blast radius.

Governance implication: Treat object-level authorisation as a required design property, not a late-stage code review item. Teams should be able to explain, for each sensitive object, who may access it and where that decision is enforced in the request path.

Related resources from NHI Mgmt Group

• Authorization Bypass Through User-Controlled Key
• Who is accountable when a cross-user authorization bypass allows integration takeover in an enterprise application?
• Who is accountable when secret values stored in project variables are exposed through an authorization bypass?
• What happens when an AI model sends user data through a sanctioned or externally controlled entity?