Reduce the risk by binding button actions to server-side authorisation and by refusing client-side changes to action targets or labels. Verify that the intended action matches the authenticated user’s privileges, and inspect requests for altered identifiers, hidden form values, or unexpected button destinations. Do not rely on the visible UI alone.
How API button hijacking works
application api button hijacking happens when the visible button in the UI is only a veneer, while the real action is decided by request parameters, hidden fields, or client-side state. The security problem is not the button itself, but the gap between what the user sees and what the backend actually authorises.
That gap matters because an attacker or even a curious user can often alter an identifier, swap an action target, or submit a request that the front end never intended to allow. If the server accepts those changes without re-checking the action and the caller’s privilege, the UI can be used to trigger a different operation than the one the page appeared to offer.
For API-driven applications, the safest mental model is that every button is only a request generator. The server must decide whether the requested operation is valid, whether the object is in scope, and whether the authenticated principal is entitled to perform it.
What controls actually reduce the risk?
Effective mitigation starts with server-side authorisation for every action, not just for page access. The backend should independently validate the requested action, the target object, and the privilege required to carry it out, even when the UI has already gated the button.
Request integrity checks matter as well. Inspect and reject altered identifiers, hidden form values, unexpected destinations, and other client-supplied fields that can change the meaning of the request. A button label such as “Approve” or “Delete” has no security value if the request body can be modified to approve a different record or call a different endpoint.
To harden the API surface, use explicit allowlists for permitted actions and destinations, and fail closed when the client submits anything outside the expected shape. The more the application depends on inferred client behaviour, the easier it becomes for a tampered request to drift into an unintended operation. See the OWASP API Security Top 10 for the broader authorisation failures that commonly surface in this class of issue, and Top 10 API Security Risks for a practitioner-oriented view of the same risk pattern.
Detection should complement prevention. Log the action requested, the object identifier, the authenticated identity, and any rejected tampering attempt so analysts can spot probing, replay, or parameter manipulation. Request inspection is especially important where the UI and API have drifted apart over time.
How should teams test for button hijacking?
Testers should treat the rendered interface as untrusted and focus on the request path behind it. Click the button, intercept the request, then change identifiers, labels, routes, and hidden values to see whether the backend still enforces the intended action and privilege boundary.
Good test cases include swapped record IDs, cross-account object references, modified action verbs, and requests sent without the UI state that originally enabled the button. If the server accepts those variations, the application is relying on the front end for control rather than enforcing policy where it counts.
It is also useful to compare what the UI says the user may do with what the API actually permits. A button that appears disabled, relabelled, or conditionally shown is not a control unless the server rejects the same operation when it is submitted directly.
Risk and Threat Considerations
Button hijacking creates a classic trust-boundary failure: the application trusts client-side presentation and state more than it trusts the request being processed. That can lead to broken authorisation, unintended object access, and actions being executed on the wrong target.
Failure mechanism: The attacker alters a request so the server receives a different identifier, destination, or action than the UI implied, and the backend does not re-validate the operation against the caller’s authority.
Impact: Sensitive actions can be executed against the wrong account or object, including approvals, changes, or deletions, and the compromise may be difficult to spot if logs only record the final action without the tampered request context.
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 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | Button hijacking often turns on unauthorized action execution. |
| Recommendation — Enforce function-level authorization for every sensitive API action. | ||
| OWASP ASVS | V8 — Authorization | The issue is whether the backend authorizes the requested action and object. |
| V16 — Security Logging and Error Handling | Tampered button requests need traceable logs and safe rejection. | |
| Recommendation — Verify server-side authorization for each action and resource. Log rejected request manipulation and preserve audit detail. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | The mitigation depends on limiting what each authenticated user can do. |
| AU-2 — Audit Events | Testing and detection require logging action, subject, and rejected tampering attempts. | |
| Recommendation — Restrict each account to the minimum actions needed. Record sensitive action attempts and authorization failures. | ||
Practitioner Guidance
What to verify: Confirm that every sensitive button action has a server-side policy check that evaluates the authenticated user, the target object, and the exact operation. If the backend can be reached directly, the UI should be treated only as convenience, not enforcement.
Common mistake: Teams often assume that hiding, disabling, or relabelling a button prevents misuse. It does not, because client-side controls are advisory unless the server independently rejects the same operation.
Practitioner takeaway: The control objective is to make the server authoritative for action, target, and privilege, so a modified request fails even when the UI appears to permit it.
Related resources from NHI Mgmt Group
- What mitigations reduce the risk of System Runtime API Hijacking?
- What mitigations reduce the risk of Application API Message Manipulation via Man-in-the-Middle?
- How should security teams reduce the risk of unsafe API consumption in application integrations?
- Why does centralising API access controls reduce operational risk in application security?