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.
What request tampering means in API security
Request tampering is not a parsing bug so much as an authorization probe: the attacker changes parameters, object IDs, or headers to learn whether the backend trusts client-supplied values too much. Because APIs often expose direct, high-value operations, even a small accepted change can reveal a broader broken authorization path.
In practice, the technique is often used against endpoints that were built for one app flow but are reachable from many clients. A service that accepts a modified request without re-checking the caller’s entitlement may expose data, actions, or relationships that the original interface never intended to disclose.
How request tampering works
The core idea is simple. The attacker sends a valid request, then mutates one field at a time, such as a record identifier, account reference, tenant marker, role hint, or header value. If the service returns another user’s record, processes an out-of-scope action, or changes behaviour in a way that should have been blocked, the request has exposed an authorization weakness.
This is why request tampering is so closely associated with broken object-level authorization. The client can never be trusted to define which object it may access, and the server must make that decision using its own access control logic rather than the caller’s supplied identifiers.
Why it is especially dangerous in mobile and API-driven systems
Mobile applications often call APIs directly, which makes the backend the real security boundary. That means the attacker does not need to defeat the user interface, only the endpoint logic. If the server assumes the app will only send “expected” values, tampering can turn a routine request into an out-of-scope read or write.
The risk is amplified when requests carry multiple trust signals at once, such as path parameters, hidden fields, bearer tokens, or custom headers. If any of those are treated as proof of entitlement instead of input to be validated, the service can accept a modified request that should have been rejected.
What defenders should look for
Request tampering is usually detected by comparing request patterns with expected authorization boundaries. Unusual object switching, repeated small parameter changes, access to records outside a user’s normal scope, and successful use of manipulated headers are all signs that the backend may be relying on client-controlled data too heavily.
Testing should focus on whether the server independently enforces object ownership, tenant separation, and action permissions at every endpoint, including older or less-visible routes. That matters because a single inconsistent check can expose the same control weakness across many flows.
Risk and Threat Considerations
Request tampering matters because it is a direct path from input manipulation to unauthorized access. When the backend accepts altered identifiers or headers as if they were trustworthy, the failure is not just a malformed request, it is a control failure that can expose data, corrupt records, or let an attacker act as a different user.
Failure mechanism: The service relies on client-supplied values to select objects or authorize actions, then fails to revalidate those values against the caller’s actual permissions.
Impact: Attackers may read or modify other users’ data, traverse tenant boundaries, trigger privileged operations, or map out broader authorization weaknesses across the API surface.
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 NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API1 — Broken Object Level Authorization | Request tampering often exposes object-level authorization flaws in APIs. |
| API5 — Broken Function Level Authorization | Tampered requests can trigger functions the caller should not reach. | |
| API8 — Security Misconfiguration | Weak trust in headers, parameters, or route handling can create tampering exposure. | |
| Recommendation — Enforce server-side object checks for every modified identifier and reject out-of-scope access. Verify function authorization on the server before executing any sensitive API action. Harden API request handling so client-controlled values cannot alter trust boundaries. | ||
| NIST SP 800-53 Rev 5 | AC-3 — Access Enforcement | Request tampering exploits missing enforcement of who may access which object or action. |
| IA-5 — Authenticator Management | Request tampering often depends on abusing authenticated sessions and request-bound credentials. | |
| Recommendation — Apply access enforcement at the service layer for each object and operation. Protect and validate request-bound credentials so they cannot be repurposed across contexts. | ||
Practitioner Guidance
Why practitioners should care: Treat request tampering as an authorization test, not a mere input-validation issue. The key question is whether the server can independently prove that the caller is allowed to touch the object or perform the action after every client-side value is changed.
Common misunderstanding: A request that contains a valid token is not necessarily a valid request for every object inside it. Authorization must be re-established per object, per action, and per context, especially where APIs are reused by multiple front ends or mobile clients.
Practitioner takeaway: Review endpoints for server-side ownership checks, tenant isolation, and consistent authorization enforcement, then verify that tampered identifiers and headers are rejected everywhere the API exposes sensitive objects or functions.
Related resources from NHI Mgmt Group
- Why do mobile interception and request tampering increase fraud risk in identity workflows?
- 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?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 31, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org