Testing 150 Mobile Banking Apps: Reverse Engineering Security Lessons

We live in an era where digital convenience defines consumer loyalty in almost all sectors. With respect to financial services, it means that mobile banking is no longer a competitive differentiator: it’s an expectation. Financial institutions with a legacy of trust and deep-rooted brand loyalty are racing to match customer demand with robust mobile platforms. The digital experience benefits are clear: increased reach, reduced operational costs, and hyper-personalized experiences.

But what’s the security cost of this transformation?

To answer that, we analyzed 150 of the most downloaded Android mobile banking apps from five global regions, Europe (EU), Middle East & Africa (MEA), Latin America (LATAM), Asia-Pacific (APAC), and North America (NA), using Guardsquare’s free mobile app security testing product, AppSweep. The goal? Understand how resilient mobile banking apps are today, and how we can help financial services app publishers do better.

How we tested the top mobile banking apps

We focused on the top-ranking Android banking apps on the Google Play Store in terms of number of downloads, scanning publicly available data only.

AppSweep automates analysis of the binary code for both iOS and for Android apps, providing deep security insights. Identified issues are presented by severity level and categorized based on the OWASP Mobile Application Security Verification Standard (MASVS) categories. To streamline our workflow, we used AppSweep’s Command Line Interface (CLI) to feed data into our analysis pipeline, enabling systematic scans across all apps and aggregating findings for macro-level security insights.

In this blog, we focus on issues classified by AppSweep, with a particular focus on issues that result in risks for reverse engineering and tampering. These issues should be reviewed and addressed before an app’s release as they can increase the amount of information leaked to attackers who are targeting your app through static or dynamic analysis.

The good news is, many of these issues are easy to fix, but often overlooked.

Here is what we found.

Key issues in mobile banking apps

No region is immune

As a mobile banking user, you expect a frictionless and secure experience while interacting with the app. From an attacker’s perspective, unresolved issues around resilience are a major win, potentially leading to insights and real-world opportunities for attackers to reverse engineer apps, tamper with data, or intercept sensitive communications.

No region is immune:

• MEA and LATAM apps lead with over seven important issues on average.
• EMEA and APAC follow closely, averaging six each.
• North American apps perform slightly better, but still average four issues per app.

Resilience is the weakest link

The OWASP Mobile Application Verification Standard (MASVS) is the industry benchmark for mobile app security. It provides a framework for developers to build secure mobile apps and for security teams to conduct thorough mobile app security testing.

Our analysis reveals a troubling trend: many vulnerabilities fall under the MASVS-RESILIENCE category, indicating insufficient protection against reverse engineering, and runtime manipulation, an especially critical concern for financial services apps.

Weaknesses in this category make mobile apps soft targets for attackers, who can use widely available tools to understand how the app works, tamper with its functionality, intercept backend communications, or even assess whether the app is susceptible to mobile malware attacks aimed at stealing personal data or redirecting financial transactions to fraudulent accounts.

Improving resilience starts with issues that are easy to fix

Surprisingly, several issues we found in mobile banking apps are easy to fix, yet they persist across the industry. Our analysis frequently uncovered the following issues:

• Kotlin assertion errors exposing sensitive app behavior
  Assertion calls can leak parameter names and internal logic, making it easier for reverse engineers to understand the app’s behavior, even through obfuscation.
• Debug logs left in production builds
  Logging calls in release builds can expose valuable information, helping attackers reverse-engineer app functionality or locate sensitive components. Logs also unnecessarily bloat the app size.
• Hardcoded HTTP/HTTPS URLs
  Embedded URLs can reveal backend endpoints and system architecture, giving attackers clues that could aid in crafting unauthorized scripts or third-party apps. Sometimes these URLs are innocuous, but each should be carefully reviewed in case the endpoint provides information to target your backend.
• Insecure TLS settings (e.g., disabled hostname verification)
  Misconfigured TLS can leave apps vulnerable to man-in-the-middle (MitM) attacks. If session tokens or API keys are intercepted, attackers may fully impersonate users without detection.
• Exposure to tapjacking attacks
  Without proper protection, malicious apps can overlay transparent or opaque windows on top of your app to hijack user input. This can lead to the theft of PINs or trigger unauthorized actions, which can be especially dangerous on security-sensitive screens like login or settings.

Quick wins for developers

The good news? Many of these vulnerabilities can be easily mitigated with simple best practices:

• Remove all Kotlin assertion calls from production builds
• Strip debug logs and logging artifacts before release
• Obfuscate or encrypt sensitive hardcoded elements, such as URLs
• Enforce secure TLS configurations, including hostname verification
• Implement tapjacking protection on sensitive screens (e.g., FLAG_SECURE, overlay detection)

A future-proof mobile app protection strategy

While quick fixes can improve security in the short term, securing a mobile banking app requires more than just patching individual issues. To provide strong, lasting mobile app protection, organizations must adopt a multi-layered security strategy that defends against both known risks and emerging threats.

A robust approach should include:

• code hardening and obfuscation to make reverse engineering significantly more difficult for threat actors.
• runtime application self-protection (RASP) to detect and block tampering attempts while the app is running.
• a secure software development lifecycle (SDLC) that integrates security at every stage. Key to this is adopting mobile app security testing (MAST) tools.
• prioritize automated MAST tools to maintain development speed without compromising security, ensuring each release is both fast and secure.
• real time threat monitoring to continuously observe the app in the field. As the threat landscape constantly evolves, field insights are essential for helping developers strengthen the app's security posture over time.

Want to learn more? Connect with a Guardsquare expert.