Frontend trusts WebSocket balance_update events as authoritative, enabling UI balance spoofing and state desync

The frontend accepted balance_update WebSocket events and updated the user's displayed balance without validating that:

• The message was authentic (origin integrity).
• The update corresponded to the current authenticated user session.
• The new balance matched server truth (e.g., via a confirmatory API fetch).

A user, or an attacker with the ability to tamper with WebSocket traffic, could therefore spoof the UI balance and put the client into an inconsistent state with the backend and the on-chain vault.

Vulnerable scenario:

1. Authenticate and open the app.
2. Intercept a legitimate balance_update message in the WebSocket stream.
3. Modify newBalance (for example, from 4.238334 to 5000000.238334).
4. The UI updates immediately, showing an incorrect available balance.

• UI integrity loss: the interface can display a fabricated balance.
• State desync: the UI may enable or disable actions based on the false balance, confusing users and support staff and increasing the chance of secondary errors during swap and withdrawal flows.

Treat WebSocket messages as advisory, not authoritative.

• On balance_update, trigger a refresh from GET /api/user/balance (or equivalent) and update the UI using API truth only.
• Validate message binding: ensure the walletAddress matches the authenticated wallet in the client context.
• Consider including a server-side sessionId / userId and validating it client-side.

Fair Casino: Fixed. Zealynx: Verified.