Why do client-side attacks create higher risk for open banking transactions than server-side controls alone?

Why client-side compromise changes the risk profile of open banking

Open banking depends on the user’s browser or app behaving honestly long enough for the user to review, consent, and approve the transaction. That makes the client side part of the trust boundary, not just a display layer. If attackers can alter the page, inject scripts, or tamper with the session, they can change the transaction itself while leaving server-side authentication intact.

The practical issue is that server controls only validate what reaches the bank. They cannot reliably vouch for what the user actually saw, compared, or intended before approval. In open banking, that gap matters because payment initiation is a high-value, one-click action, and financial services identity security has to account for both strong authentication and the integrity of the approval step.

That is why client-side attacks create higher risk than server-side controls alone. The attacker does not need to defeat the bank’s authentication policy if they can manipulate the human decision point, for example by swapping the beneficiary account, inflating the amount, or masking the true destination before consent is captured.

What client-side attacks can change that server controls may not see

Client-side attacks are dangerous in open banking because they target the trust relationship between the user and the transaction screen. Once a browser, mobile webview, or local extension is compromised, the attacker can alter form values, intercept requests, or present a false confirmation screen that still produces a valid server-side approval.

This is a different failure mode from a traditional server-side weakness. A server can enforce authentication, authorization, and limits, but it cannot guarantee that the user approved the correct payee or amount if the client was already manipulated. In that sense, the client becomes part of the attack path, not just the delivery channel.

The risk is amplified in open banking because the transaction often moves quickly from consent to execution. There may be little opportunity for downstream review once the approval has been signed or submitted, so the compromise can translate directly into fraud, mistaken transfer, or account misuse.

Client-side tampering also weakens assurance signals that organisations often over-trust, such as “the user authenticated successfully” or “the bank received a valid approval.” Those signals may be true while still being insufficient, because they say nothing about the integrity of the user interface, the session state, or the data the user relied on.

Why browser and session integrity matter more than authentication strength alone

Strong authentication helps, but it does not solve client compromise. If the browser session is hijacked or the page is altered after login, the attacker can ride on the user’s authenticated context and submit a fraudulent instruction that appears legitimate to the bank.

That is why open banking controls need to treat client integrity as a security requirement in its own right. The core question is not only whether the user is authenticated, but whether the approval artefact, session, and displayed transaction details were protected from tampering throughout the consent flow.

For practitioners, this means monitoring for integrity failures that sit between authentication and execution: unexpected script injection, DOM manipulation, request parameter substitution, local malware, malicious extensions, and consent screens that do not visibly bind the payment details to the approval step. A secure server cannot fully compensate for a client that can lie about what the user approved.

Server-side controls remain essential for validation, risk scoring, and transaction enforcement. But in open banking they are a second line of defence, not the whole model. If the endpoint is compromised, the attacker may not need to breach the bank at all.

Risk and Threat Considerations

Open banking client attacks create a fraud path that is attractive because they exploit the last trusted interaction before payment execution. The main exposure is not just credential theft, but approval manipulation, which can turn a legitimate session into an authorised fraudulent transfer.

Failure mechanism: The attacker compromises the browser, app, or session and changes the payment context, so the user approves one thing while the bank processes another.

Impact: This can produce authorised-push-payment fraud, beneficiary substitution, amount inflation, consent replay, or silent redirection that is hard to distinguish from a valid customer action.

Practitioner Guidance

What to verify: Verify that the transaction details shown to the user are cryptographically or procedurally bound to the approval step, not just rendered in the interface. If the display can be changed without changing the approval artefact, the control is too weak for high-risk payments.

Common mistake: Treating strong authentication as sufficient protection for open banking. Authentication proves who entered the session; it does not prove the session was trustworthy when the payment was approved.

What good looks like: The approval flow makes tampering obvious, transaction details are fixed at the point of consent, and server-side validation rejects requests that do not match the approved payment context.

Practitioner takeaway: For open banking, the security objective is to protect the integrity of the approval moment, not only the login event. If the client can alter what the user sees, the transaction is already under attacker influence.

Related resources from NHI Mgmt Group

• Why do LLM-assisted client-side attacks create higher risk than manual reverse engineering?
• Why do exposed client-side controls increase risk for digital banking applications?
• Why do client-side secrets create a bigger risk than source-code secrets alone?
• Why do client-side attacks create such a high risk for payment pages and web forms?