Mobile VAPT For A Challenger Bank iOS And Android Application

We began by understanding how the apps worked and who might attack them. Workshops with the mobile, backend and product teams mapped every feature, from onboarding and payments to card controls, and the data each one handled. Every feature was considered from an attacker's point of view.

Together, we identified the most realistic threats, including stolen or lost phones, malware on rooted or jailbroken devices, attackers intercepting traffic on public Wi-Fi and fraudsters trying to take over accounts. Each threat was ranked by likelihood and impact, so testing time went where it would matter most for real customers.

The threat model gave the whole team a shared understanding of mobile risk before any testing started. It also became a living document the bank now updates with every major new feature, keeping security thinking part of product planning. It also helped the product team decide which features needed extra protection before release.

We examined the compiled iOS and Android apps without running them, looking for weaknesses built into the code itself. Automated tools were combined with careful manual review of the most sensitive parts of each app. Both platforms were reviewed in the same level of detail.

The analysis found hard-coded API keys, debug features accidentally left enabled in production builds and third-party libraries with known vulnerabilities. On Android, several internal components were exposed to other apps on the device, which could have allowed a malicious app to trigger sensitive banking actions without the customer's knowledge.

Each finding was reported with the exact file and line, an explanation of the risk and a recommended fix in Swift or Kotlin. Many of these issues were resolved within days, and automated checks were added to the build process so they cannot quietly return. Developers now receive static analysis results within minutes of each build, as part of their normal workflow.

Some vulnerabilities only appear while an app is running. Using instrumentation tools like Frida, we hooked into both apps on real and emulated devices, watching and changing their behaviour in real time as an attacker would. Testing covered every supported operating system version.

We bypassed jailbreak and root detection, tampered with values in memory and manipulated responses from the bank's servers to see how the apps reacted. Several security checks were being made only on the device rather than on the server, which meant a skilled attacker could simply switch them off and continue unchallenged.

The findings led to important changes, such as moving critical checks to the server and strengthening tamper detection. The apps now behave safely even when running on compromised devices, protecting customers who may not realise their phones are at risk. Runtime protections are now tested with every release, so new features cannot quietly weaken the apps' defences.

One of the most serious findings was how the apps stored data on the phone. Account numbers, balances and recent transactions were saved in plain text, readable by anyone with access to an unlocked or compromised device. It turned out to be one of the four critical issues we found.

We worked with the developers to redesign local storage completely. Sensitive information is now encrypted using keys protected by the iOS Secure Enclave and Android Keystore, cached data is minimised and cleared on logout, and screenshots of sensitive screens are blocked in the app switcher so balances cannot be glimpsed accidentally.

Plaintext storage of sensitive data has been eliminated from both apps. Even if a customer's phone is lost or stolen, their banking information stays protected, which was a key point in securing regulatory approval for the public launch. The same secure storage approach is now used by default for every new feature the mobile team builds.

Face ID, Touch ID and fingerprint login make banking apps easy to use, but only if they are implemented securely. We tested exactly how each app confirmed a successful biometric check before granting access to the account. Both the iOS and Android flows were tested in depth.

On both platforms, the apps trusted a simple true or false result from the biometric prompt, which could be forced to succeed using runtime manipulation. An attacker with brief access to a phone could have opened the banking app and moved money without ever matching the owner's face or fingerprint.

The biometric flow was rebuilt so a successful scan unlocks a cryptographic key stored in secure hardware, which is then required to talk to the bank's servers. Faking the result no longer works, closing one of the four critical vulnerabilities before launch. Customers still enjoy fast biometric login, but with far stronger protection behind the scenes on every device.

We examined how the apps created, stored and ended user sessions. Strong session management ensures that once a customer logs out, or their phone is lost, nobody else can continue using their banking session. Every login and logout path was tested thoroughly.

Session tokens remained valid on the server even after users logged out, and some lasted for days without any activity. A stolen token could therefore be reused long after the customer believed they were safely signed out, giving an attacker quiet, continued access to their account, card controls and payment features.

Sessions are now properly ended on the server at logout, expire after short periods of inactivity and are tied to the device they were created on. Customers can also view and remotely end active sessions from settings, giving them more control over their own security. Suspicious session activity now triggers an alert, helping the fraud team act quickly when an account is at risk.

Banking apps must protect data as it travels between the phone and the bank. We intercepted traffic from both apps to test whether an attacker on a public Wi-Fi network could read or change it along the way. Both apps were tested on a range of untrusted networks.

Neither app used certificate pinning, so a malicious network could impersonate the bank's servers and quietly read or alter traffic. We also found that some API calls exposed more personal information than necessary and that older, weaker encryption settings were still accepted by parts of the backend infrastructure.

Certificate pinning was introduced with a safe rotation strategy, weak encryption settings were disabled and API responses were trimmed to include only what the apps needed. Customers are now protected even when banking over untrusted networks in cafés, airports or hotels. Pinning is monitored continuously, and certificates can be rotated safely without forcing customers to update.

The final goal was proving compliance with the OWASP Mobile Application Security Verification Standard. We mapped every control to the evidence gathered during testing and remediation, creating a clear picture of where each app stood. Every control was checked against the standard's requirements.

During a four-week remediation sprint, our consultants paired with the mobile developers on the trickiest fixes and retested each one as soon as it was ready. By the end, all 18 findings, including the four critical issues, were fixed and verified on every supported operating system version across both platforms.

Both apps achieved MASVS Level 2, exceeding the Level 1 minimum set by the regulator. Approval was granted on schedule, and the bank launched to 500,000 customers with a mobile security foundation it can build on confidently as new features are added. Mobile security testing is now part of every major release, keeping both apps aligned with the standard.