Your mobile banking app is one of the most exposed components of your digital infrastructure. It runs on devices you do not control, connects to backends you do, 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 in a bank's estate.
This article explains what a mobile banking security assessment covers, what testing typically finds in African banking apps, and why the most critical vulnerabilities often sit in the backend API rather than in the app.
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, because 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 application itself: the Android APK, the iOS IPA, or both
- The backend APIs the app communicates with
- The authentication infrastructure (session management, token handling)
- The CDN and web services that serve 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's balance, and potentially its transaction history, personal details and account numbers. This is an insecure direct object reference (IDOR), and it is among the most common critical findings in mobile banking assessments.
Scenario 2: Insecure session token storage
The app stores the authentication token in the device's shared storage or in another 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 talking only to your legitimate server (certificate pinning), but the implementation is weak or easily bypassed. An attacker on the same Wi-Fi network (airport, hotel, cafe) can intercept all traffic between the app and your servers and capture credentials and session tokens.
Scenario 4: Business logic bypass
The app enforces a daily transaction limit of RWF 500,000, but only on the client side, in the app code; the server never checks it. An attacker who modifies the requests can send transactions for arbitrary amounts and bypass 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 other 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 of 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 every file system write to see whether the app stores PINs, tokens or transaction data in cleartext
- Inspect process memory for sensitive data such as PINs and session tokens
- Hook into the app's SSL/TLS handling to bypass certificate pinning
- Test for runtime manipulation with tools such as Frida
API security testing
We capture every API call the app makes and test it manually. This is usually where the most critical findings are. We test against the OWASP API Security Top 10 (2023):
- 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 a current TLS version (TLS 1.2 minimum, TLS 1.3 preferred), that certificate pinning is implemented correctly and cannot be trivially bypassed, and that no sensitive data travels in URL parameters, which end up in server logs.
iOS vs Android: key differences in testing
Android and iOS have different security models, and if your app runs on both, both need testing:
- Android: more accessible for testing (APK extraction, rooted devices, sideloading). Its higher market share in East Africa means a higher volume of attacks.
- iOS: more restricted, with a jailbreak required for deep testing. App Store review provides some security gatekeeping, but it is no substitute for testing.
- Common to both: backend API vulnerabilities affect both platforms equally. An IDOR on the server doesn't care which client is making the request.
The banking API: the backend nobody tests
Many banks test the mobile app but not the API it talks to, which is the wrong way round. The API is where business logic runs and transactions are executed, so it is where the most critical vulnerabilities live. A vulnerability in the API affects every client at once: the mobile app, the web portal and any third-party integration.
See our dedicated article on API security in modern banking for the full breakdown of common API vulnerabilities in banking.
How often to 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 N° 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 provides manual penetration testing for banks, fintechs, telecoms, government and healthcare institutions across Africa, and mobile banking apps are one of the places where the most critical issues tend to surface. Our team tests the app, the APIs behind it and the business logic that ties them together, then writes a report that explains exactly what we found.
For scope, methodology and deliverables, see our mobile application penetration testing service page. 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 for 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 N° 50/2022 requires and give your development team clear remediation guidance they can act on.