MoSecureMost mobile security mistakes at banks don't come from carelessness. They come from assumptions that were reasonable once, are still partly true, and so never get re-examined. Here are five we hear often, plus one about our own category.
1. “iOS is secure, so the risk is on Android”
What's true: Apple's closed App Store and strict sandbox stop most of the mass-market malware that hits Android, and Android is where most Indonesian customers are: about 79% of mobile users in September 2026, against about 21% on iOS.2
Where it stops holding: one in five customers is still a large group, and jailbroken iPhones exist. On a jailbroken device, your app can be studied and modified like any other. And social-engineering scams, where the customer is talked into sending the money, don't depend on the operating system at all.
Instead: treat iOS as safer, not safe. Apply the same integrity checks and server-side decisions to both apps, even if the threat volume differs.
2. “Obfuscation is enough”
What's true: obfuscation makes decompiled code far harder to read, and it raises the cost of studying your app.
Where it stops holding: it slows down someone reading the app. It doesn't stop someone attaching to the app while it runs, or rebuilding a modified copy and distributing it. And anything shipped inside the app, including keys and configuration, should be assumed readable by a determined attacker eventually.
Instead: combine build-time hardening with checks while the app runs, keep real secrets on the server, and let the server verify that it's talking to a genuine copy of your app.
3. “We passed our pen test”
What's true: pen tests find real problems, and regulators and auditors expect them.
Where it stops holding: a pen test is a snapshot. It covers one build, within a fixed scope and a fixed number of days. Your app changes with every release; attackers work on it every day, with no deadline and the newest tools. A pen test checks your app once. Attackers check it every day after.
Instead: keep the pen test, and add protection that keeps working after it, on every device and every session, with visibility into what is actually happening in the field.
4. “Root detection solves it”
What's true: a rooted or jailbroken phone is one of the clearest risk signals there is.
Where it stops holding: tools exist specifically to hide root from apps, and they are actively maintained. A single yes/no check inside the app can be fooled, and a determined attacker can sometimes pass every on-device check.
Instead: use layered checks rather than one, add hardware-backed attestation from the platform where you can, and make the final decision on the server, where it can't be patched out of the app.
5. “Security lives on the server; the app is just the front end”
What's true: the server is where enforcement belongs, and server-side controls remain essential.
Where it stops holding: today's attacks happen on the phone. Malware draws overlays, abuses Accessibility, or lets an operator control the device; the campaign Group-IB documented in September 2026 runs a cloned banking app in a hidden work profile.3 The server then sees the right user, the right password and a valid OTP. The evidence that something is wrong exists only on the device.
Instead: bring device and session evidence into the server's decision, and make sure that evidence is fresh and comes from the real app, not a replayed or copied token.
And one about our own category: “Add RASP and the app can't be broken”
No honest vendor should claim this. In-app protection raises the cost and effort of attacking an app, detects many attacks as they happen, and lets you respond. It does not make an app unbreakable, and it does not replace secure design.
OWASP's mobile security standard says the same: obfuscation, anti-tampering and runtime self-protection are defence-in-depth measures, and “must not be used as a substitute for proper security architecture”. It also warns that the variety of Android devices can cause false positives that exclude legitimate users.1 That is why we recommend starting in report-only mode, reading the data from your real users, and only then switching threats to block.
Summary
| Assumption | What it gets right | What it misses |
|---|---|---|
| iOS is secure | Far less mass malware | Jailbreaks, and scams that ignore the platform |
| Obfuscation is enough | Slows down reading the code | Attacks on the running app, and rebuilt copies |
| We passed our pen test | Real issues found and fixed | Every day and every release after the test |
| Root detection solves it | A strong risk signal | Hiding tools; one check is easy to fool |
| Security lives on the server | Enforcement belongs there | The evidence that exists only on the device |
| RASP makes the app unbreakable | Raises the attacker's cost | Secure design is still required |
Where MoSecure fits. MoTogu hardens your finished app and then keeps checking it while it runs, for rooted or jailbroken devices, hooking, debuggers, emulators, repackaging and network interception, with responses you set and change from the server. MoNetra brings fresh, hardware-attested device and session evidence into your backend's decision at login, device binding and transfer. Neither replaces secure design or your existing controls; both are layers on top of them.
Related: Five stages of mobile fraud · Gigabud and the cloned banking app
Sources
- OWASP MASVS: MASVS-RESILIENCE, Resilience against reverse engineering and tampering
- StatCounter: Mobile operating system market share in Indonesia (September 2026)
- Group-IB, 9 Sep 2026: Vwork, weaponized open-source software as an add-on for Gigabud
Figures are as reported by the sources above at the time of writing. Spotted an error? Email contact@mosecure.id and we will correct it.