Every script runs as the user: locking down third-party code on an Indonesian e-wallet's web app

The situation

An e-wallet in Indonesia served users through a mobile app and a web app. The web app let users top up, pay merchants, transfer to bank accounts and withdraw. Over the years, marketing, product and support had added scripts from analytics providers, a tag manager, a chat widget, a session recorder, a performance monitor and several advertising pixels. Most loaded on every page, including the transfer and withdrawal flows, and several were loaded directly from vendors' servers.

Why now. On 29 October 2026, malicious code replaced a third-party performance script loaded by Polymarket's website and used signed-in traders' sessions to withdraw funds; Polymarket put the loss at about $2.7 million¹². No passwords or keys were needed: the script simply acted with the access the open page already had¹. The card side of the business was already subject to PCI DSS v4 requirements that scripts on payment pages be authorised and protected from tampering, and that changes to payment pages be detected³, and Indonesia's Personal Data Protection Law applies to the personal data those scripts could see⁴. The board wanted the risk removed, not just documented.

What had to be true

• No third-party code on money-moving pages.
• Every remaining script known, justified and integrity-checked, served from the e-wallet's own domain.
• The browser holds as little power as possible: no long-lived tokens, no direct calls to vendors.
• A live session is not enough to move money: transfers and withdrawals need fresh confirmation.
• Changes are noticed: unexpected scripts or header changes on sensitive pages raise alerts.

Architecture

The data flow, end to end

The hard part: taking scripts away from the teams that rely on them

Every script had an owner who needed it: marketing measured campaigns, support used the chat widget, product watched session recordings. Simply deleting them would have failed politically and practically. The team ran an inventory first, recording for each script what it did, who owned it, which pages it loaded on and what data it could read. Many turned out to duplicate each other or to have no current owner.

The bigger change was architectural. The web app moved to a backend-for-frontend: the browser talks only to the e-wallet's own server layer, which holds session tokens and calls internal services and vendors on the user's behalf. The OpenTelemetry demo's front-end shows the same shape: client-side code calls the app's own API routes, which then call the backend services⁵. With that in place, analytics and marketing events could be sent server-side, so most tags no longer needed to run in the browser at all.

For the scripts that remained, such as the chat widget on help pages, the team self-hosted pinned versions with integrity hashes, so a change at the vendor could not silently change the code running in users' browsers, and listed every allowed source in a Content Security Policy with violation reporting turned on. Vendor updates became a deliberate change, reviewed like any other dependency.

How it ran

Key decisions and trade-offs

What I'd do again, and differently

Again: strip the money pages in week one. It removed most of the risk before the longer re-architecture began. Differently: run the Content Security Policy in report-only mode from the first day of the inventory; its reports found scripts that nobody had listed. Related: architecture lessons from the Binance hack, the 2 November tech news, securing AI coding tools and where I work.

If you run a wallet, marketplace or fintech in Indonesia or across Southeast Asia, see the Singapore and Southeast Asia page, or analyse your challenge and bring the result to a call.