Request Tampering

Request tampering is the deliberate modification of parameters, identifiers, or headers in an API call to see whether the service accepts out-of-scope access. It is a common way to expose broken object-level authorization, especially in mobile applications where attackers interact directly with endpoints.

Expanded Definition

Request tampering is a test technique and an attack pattern in which a requester changes fields that should be trusted by the application, then observes whether the service still performs an action outside the requester’s authority. In practice, the altered value may be an object identifier, account reference, role hint, file path, tenant ID, price, or a header that influences routing or access decisions.

Within application and API security, the concept is closely tied to broken object-level authorization and broken function-level authorization. The key issue is not that the request is malformed, but that the backend accepts a validly structured request with unsafe business meaning. Guidance across the industry is still evolving, but the security expectation is clear: servers must verify authorization on the server side, using the authenticated identity and policy, rather than trusting client-supplied context. For a broad governance frame, the NIST Cybersecurity Framework 2.0 is relevant because it emphasises access control, secure architecture, and continuous risk management.

The most common misapplication is treating request validation as authorization, which occurs when teams block only obviously invalid input while still trusting changed IDs, headers, or hidden parameters to determine what the caller may access.

Examples and Use Cases

Implementing protections against request tampering rigorously often introduces extra server-side checks and tighter API design constraints, requiring organisations to weigh developer convenience against stronger authorization assurance.

• A mobile banking app sends API requests with an account ID in the body. An attacker swaps the ID to another customer’s account and checks whether balances or transfers are still returned.
• An e-commerce checkout accepts a price value from the client. The user edits the request to reduce the total and tests whether the backend recalculates the amount or accepts the tampered value.
• A support portal passes a ticket owner reference in a query parameter. The requester changes the identifier to another user’s ticket and verifies whether private case details are disclosed.
• An internal admin API relies on a role header supplied by a proxy or client library. The attacker modifies the header to see whether privileged actions can be triggered without corresponding authorization.
• A file download endpoint accepts a path or document ID. The attacker alters the parameter to access documents outside the intended scope, exposing weak object-level controls.

For testing methodology, request tampering is often paired with access-control review and adversarial path exploration documented by the OWASP family of guidance, even though the core issue is broader than any single application stack. In mature programmes, these cases are also mapped to policy checks and logging requirements in frameworks such as NIST SP 800-53.

Why It Matters for Security Teams

Request tampering matters because it exposes whether trust boundaries are actually enforced where the decision is made. If a service accepts a manipulated parameter as authoritative, the result can be unauthorized data disclosure, privilege escalation, fraud, or cross-tenant access. For security teams, the issue is less about a single malformed request and more about whether the application consistently re-derives authority from authenticated context and policy. That is why server-side authorization, object scoping, and defensive logging are essential in API and microservice environments.

The term is especially important where identity and application logic intersect. In modern systems, a legitimate user, service account, or NHI may have valid authentication but still attempt actions outside its intended scope if the endpoint trusts client-supplied object references. Under NIST Zero Trust Architecture, each request should be evaluated as though it were untrusted until policy checks confirm otherwise. Teams also use OWASP authorization guidance to harden endpoints against parameter manipulation and indirect object reference abuse.

Organisations typically encounter the impact only after an unauthorized access event or fraud investigation, at which point request tampering becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• What is the difference between network trust and request-level identity trust?
• Why do access-request workflows matter for NHI governance?
• How should organisations use AI in access request approval without weakening control?
• What is the difference between access request automation and access governance?