A financial application runs substantial logic in the browser. What must never be trusted, and what protections are architectural?

What must never be trusted

Anything the client sends or computes. Validation, authorisation, price calculation, limit checks and eligibility rules must all be enforced server-side regardless of what the client does — client-side versions exist for user experience, not for correctness.

A client-side check is a hint to the user, not a control.

The architectural protections

• Tokens stored so that a script cannot read them. A token in local storage is readable by any injected script; an HTTP-only cookie is not — and the choice is architectural rather than a preference, because it determines what a cross-site scripting flaw can do.
• A content security policy, which is the most effective single mitigation against injected scripts and which requires the application to be built without inline scripts and arbitrary sources.
• Strict handling of any content rendered from user input or from a model, since output rendered into a page is an injection vector and the conventional defences apply.
• Third-party script governance. Every third-party script executes with the page's full privileges — an analytics or advertising script can read the DOM and issue authenticated requests — which makes each one a supply-chain decision rather than a marketing one.
• Subresource integrity on anything loaded from a third party, so a compromised CDN cannot substitute the file.

The financial-application specific requirements

• Session handling for a high-value account: short-lived tokens, re-authentication for consequential actions, and visible session management so a user can see and terminate other sessions.
• Sensitive data not persisted client-side beyond what the session needs, since a shared or compromised device exposes it.
• Clear indication of what is authoritative. A displayed balance is a cached value; the number that matters is the one the server used at execution, and the interface should not present the two as interchangeable.

The habit that causes most of the exposure

Adding a third-party script because a business team asked for it. Each is individually justified, each runs with full privileges, and the aggregate is a page whose security posture is determined by the least careful vendor on it.

A review with a named approver for anything added to the page is the control, and it is usually absent because the page is treated as marketing surface rather than as an execution environment.