Checklist · Mobile apps
Protect a customer app on devices you do not control
What I check when a bank or fintech adds in-app protection to its customer app, from response policy to telemetry in the SOC. Shielding is one layer; the backend still has to hold.
- 21 checks
- 7 critical
- Saved in your browser
- 0/21
- checks ticked
- 0/7
- critical checks
Policy
0/4Build and release
0/5Runtime protection
0/5Backend controls
0/3Telemetry and testing
0/4Go deeper
When a checklist is not enough.
A checklist tells you what is missing. An assessment tells you what it means, what to fix first and what it will cost.
- 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 appsI 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.Expertise · Area 05
- API securityThe worst API attacks look like valid requests. I check what you expose, what the edge can enforce and what only your code can fix.Expertise · Area 02
Does a banking app need RASP if the backend is secure?
Yes, as a separate layer. RASP (runtime application self-protection) defends the app on the customer’s device against hooking, tampering, repackaging and rooted operating systems, which backend controls cannot see. The backend must still assume any client could be compromised, because attackers can call APIs (application programming interfaces) directly from a script. The two answer different questions and work best together.
How do you roll out app shielding without locking out customers?
Release every detection in report-only mode first and review the telemetry by device model, operating system version and app version. Investigate devices that falsely trip root detection with the vendor. Then enforce the highest-confidence, highest-risk detections first, such as active hooking during a transaction or a repackaged app. Prepare call-centre scripts before restricting rooted devices, because blocked customers will call.
How often should a protected mobile app be retested?
Test every significant release as an attacker would: on a rooted or jailbroken device, with a hooking framework attached, as a repackaged copy and on an emulator. Confirm the app responds as the policy says and that each event reaches the SIEM (security information and event management) platform. Re-review the policy after every major iOS and Android release, because new operating systems change what detection can see.