Expertise 05 · Mobile apps
Help your customer app defend itself on any phone
I have tuned in-app protection for a leading private bank’s mobile app. I check what your app detects, how it responds and what the backend still trusts.
In short
Mobile app security protects customer apps on devices you do not control, from rooted phones and hooking tools to repackaged clones. I assess it with a mobile threat model, a review of RASP (runtime application self-protection) and app shielding policy, checks of what the backend trusts, and testing aligned with MASVS, the Mobile Application Security Verification Standard, so protection holds without locking out real customers.
What I check
- In-app protection and RASP policy per threat
- Anti-tamper, anti-hooking and anti-repackaging
- Secrets and keys inside the app package
- Backend checks that hold if the app is compromised
- OWASP MASVS-aligned testing per release
- Runtime threat telemetry to the SOC and fraud team
The threats
What this area has to stop.
The attacks I see most often in this area, and what they cost when they land.
Open the attack simulator- Threat 01Repackaged banking appA modified copy of your app is shared through links or third-party stores to steal credentials.Credentials and OTPs capturedSee which layer stops it
- Threat 02Runtime hooking on a rooted phoneTools such as Frida change the app’s behaviour while it runs, skipping checks or altering values.Transactions altered after approvalSee which layer stops it
- Threat 03Overlay and accessibility abuseMalware draws fake screens over the app or reads the screen through accessibility services.Credentials and OTPs read off the screen
- Threat 04Secrets in the app packageAPI keys, endpoints and logic are pulled out of the binary through static analysis.Backend attacked directly
- Threat 05Direct API calls that skip the appOnce the API is understood, a script calls it directly and every in-app control is bypassed.Shielding sidestepped entirely
The defences
How good looks, layer by layer.
- 01Distribution and clonesWatches for repackaged copies of the app in the wild and gets them taken down.Store monitoring, takedown requests
- 02Device integrityDetects rooted, jailbroken, emulated or debugged devices before sensitive actions.Root and jailbreak checks, attestation
- 03App hardeningMakes the package hard to read or modify: obfuscation, encryption and integrity checks.Obfuscation, anti-tamper, anti-repackaging
- 04Runtime self-protectionDetects hooking and tampering while the app runs, and responds as the policy says.RASP, anti-hooking, anti-debugging
- 05Server-side trustAssumes the client may be compromised and validates every transaction on the server.Device binding, step-up auth, fraud rules
Maturity
Where are you on the staircase?
Four levels I use to score this area. Most improvement plans aim one step up within a year.
- L0Unprotected
- No in-app protection; secrets in the binary
- Rooted and jailbroken devices treated as normal
- L1Shielded, report-only
- Shielding SDK integrated; detections only reported
- Telemetry sits in a vendor console nobody reads
- L2Enforced per threat
- Hooking and repackaging blocked; rooted phones graded
- Policy agreed with fraud, digital and support teams
- L3Tested every release
- MASVS-aligned resilience tests before each release
- Runtime events correlated with transactions in the SOC
Measure it
Four numbers worth tracking.
- KPI 01Detections by type and app versionShows which threats real customers face, and whether a release changed the picture.
- KPI 02Enforced versus report-only rulesTracks progress from watching threats to stopping them, one detection at a time.
- KPI 03Support calls from device blocksThe cost side of enforcement. Rising calls mean the policy needs a graded response.
- KPI 04Releases with resilience testsShare of significant releases tested on rooted devices and with hooking tools before launch.
Frameworks I assess against
- OWASP MASVS
- OWASP MASTG
- OWASP Mobile Top 10
Work with me
How I can help with this area.
- Mobile app security assessmentI model the threats to your iOS and Android apps, review the protection you have or plan, and set a policy that stops attacks without locking out customers.1–2 weeksFixed fee
- Application architecture reviewI take one application or platform and trace every path from the internet to its data, then show which controls hold, which are missing and what to fix first.1–3 weeksFixed fee
- Mobile app protection checklistPolicy, build, runtime, backend and telemetry checks for a protected customer app.Free · interactive
Proof from delivery
What is RASP in mobile app security?
RASP (runtime application self-protection) is protection built into the mobile app that checks its environment while it runs. It detects rooted or jailbroken devices, hooking frameworks, debuggers, emulators and tampering, then responds according to a policy you set: report, restrict a feature, ask for extra verification or close the app. It is usually added through an SDK (software development kit).
Is app shielding enough to secure a banking app?
No. App shielding makes the app harder to analyse, modify or manipulate, but an attacker who understands your APIs (application programming interfaces) can call them directly and skip the app entirely. Server-side authorisation, transaction validation, device binding and fraud monitoring must still assume the client is compromised. Shielding raises the cost of attacking the device; it does not replace backend security.
What is app repackaging?
App repackaging is when an attacker decompiles a genuine app, adds malicious code, re-signs it and distributes the copy through links, third-party stores or messaging apps. Customers who install it hand over credentials and one-time passwords. Integrity checks stop modified copies running, platform attestation lets the backend reject them, and store monitoring with takedown requests limits how far clones spread.
How does OWASP MASVS help with mobile app security?
MASVS, the Mobile Application Security Verification Standard from OWASP (the Open Worldwide Application Security Project), defines what a secure mobile app should do across control groups for storage, cryptography, authentication, network, platform interaction, code quality, resilience and privacy. Its companion, the MASTG (Mobile Application Security Testing Guide), explains how to test each one. Together they turn mobile security into testable requirements for every release.
Which mobile protection platforms do you work with?
Ravindu Fernando, a Colombo-based application security consultant, has rolled out Zimperium in-app protection for a leading private bank’s mobile app, covering policy tuning, SDK (software development kit) integration support and third-party SDK conflict resolution. Assessments stay vendor-neutral: the threat model, response policy, backend trust and test plan apply whichever shielding product you use.