Your mobile banking app is the most attacked component of your digital infrastructure. It runs on devices you do not control, connects to backends you do control, and is installed by every customer your bank serves, each of them a target in their own right. Yet it is one of the most commonly under-tested components we encounter.
This article explains what a mobile banking security assessment actually covers, what we typically find in African banking apps, and why the backend API (not just the app itself) is often where the most critical vulnerabilities live.
Mobile banking in East Africa: a rich target
East Africa runs on mobile financial channels, and Rwanda shows the pace. The National Bank of Rwanda's Annual Report 2024/25 records mobile banking as the fastest-growing payment channel in the country: transfer values more than doubled year on year, up 112 percent from RWF 6,645 billion to RWF 14,088 billion, while transaction volumes rose 92 percent. Growth on that curve makes mobile banking apps a high-value target: compromising one app can expose the accounts and transaction capabilities of every customer it serves.
The attack surface is larger than most banks realise:
- The Android APK and/or iOS IPA (the application itself)
- The backend APIs the app communicates with
- The authentication infrastructure (session management, token handling)
- The CDN and web services serving app updates
- Deep links and inter-app communication
What can go wrong: real attack scenarios
Scenario 1: IDOR on account endpoints
The app calls GET /api/accounts/12345/balance to fetch your balance. If the backend doesn't verify that account 12345 belongs to the authenticated user, any logged-in customer can fetch any account balance, and potentially transaction history, personal details, and account numbers. This is among the most common critical findings in our assessments.
Scenario 2: Insecure session token storage
The app stores the authentication token in the device's shared storage or in an unprotected location. A malicious app installed on the same device, or physical access to an unlocked phone, allows token theft and therefore full account access without any credentials.
Scenario 3: Broken certificate pinning
The app is supposed to verify that it is only communicating with your legitimate server (certificate pinning). The implementation is weak or bypassed. An attacker on the same WiFi network (airport, hotel, cafe) can intercept all traffic between the app and your servers, capturing credentials and session tokens.
Scenario 4: Business logic bypass
The app enforces a daily transaction limit of 500,000 RWF. This limit is enforced client-side (in the app code), not server-side. An attacker modifying requests can send transactions for arbitrary amounts, bypassing the limit entirely.
What we test in a mobile banking security assessment
Static application analysis
We decompile the APK (Android) or unpack the IPA (iOS) and review the code for:
- Hardcoded credentials, API keys, or secrets in the binary
- Insecure cryptographic implementations (weak keys, ECB mode encryption)
- Sensitive data in app resources, config files, or compiled strings
- Debug features left enabled in production (logging sensitive data, debug endpoints)
- Improper use of Android intents or iOS URL schemes enabling deep-link attacks
Dynamic analysis
We run the app on a controlled device and instrument it at runtime:
- Monitor all file system writes: does the app store PINs, tokens, or transaction data in cleartext?
- Inspect memory for sensitive data at rest
- Hook into the app's SSL/TLS handling to bypass certificate pinning
- Test for runtime manipulation using tools like Frida
API security testing
Every API call the app makes is captured and tested manually. This is where the most critical findings usually are. We test against the OWASP API Security Top 10:
- Broken Object Level Authorization (BOLA): accessing other users' data
- Broken Authentication: token weaknesses, session fixation
- Broken Object Property Level Authorization: exposing fields that should be hidden
- Unrestricted Resource Consumption: missing rate limits
- Broken Function Level Authorization: accessing admin or higher-privilege operations
Network and transport security
We verify that all traffic is encrypted with current TLS versions (TLS 1.2 minimum, TLS 1.3 preferred), that certificate pinning is correctly implemented and not trivially bypassable, and that no sensitive data is transmitted in URL parameters (which appear in server logs).
iOS vs Android: key differences in testing
Android and iOS have different security models, and both need testing if your app is on both platforms:
- Android: More accessible for testing (APK extraction, rooted devices, sideloading). Higher market share in East Africa means higher attack volume.
- iOS: More restricted (jailbreak required for deep testing). App Store review provides some security gatekeeping but does not substitute for testing.
- Common to both: Backend API vulnerabilities affect both platforms equally. IDOR on the server doesn't care which client is making the request.
The banking API: the backend nobody tests
Most banks test the mobile app but not the API it talks to. This is backward. The API is where business logic runs, where transactions are executed, and where the most critical vulnerabilities live. A vulnerability in the API affects all clients simultaneously: mobile app, web portal, third-party integrations.
See our dedicated article on API security in modern banking for the full breakdown of common API vulnerabilities we find.
How often should you test?
At minimum:
- Before releasing a new major version of the app to the public
- After significant backend changes (new APIs, new features, new third-party integrations)
- Annually, if you are a BNR-regulated institution, as part of the penetration testing programme BNR Regulation No 50/2022 requires
- After any security incident involving the app or its backend
For high-transaction mobile banking apps, we recommend a quarterly assessment cycle aligned with your release schedule. See our penetration testing cost guide for what this looks like in practice.
How we can help
IMIZI Cyber is an offensive security firm based in Kigali, testing mobile banking apps for regulated institutions across Africa: banks, fintechs, telecoms, government ministries, healthcare systems, and other supervised enterprises. Mobile application security is one of the areas where we find the most critical issues. Our team tests the app, the APIs behind it, and the business logic that ties them together, and writes the report that explains exactly what we found.
For more on how we approach mobile and application security, see our security assessments service page, and if your channels include mobile money or USSD, our article on USSD security testing covers that attack surface in depth. If your mobile banking app has never been tested by people who understand certificate pinning bypass, BOLA on banking endpoints, and USSD-to-app transaction flows, book a free call to scope an assessment. Our reports supply the technical evidence BNR Regulation No 50/2022 requires and give your development team clear, actionable remediation guidance.