How to Ensure Mobile Banking App Security

Mobile banking applications have quickly become a central part of consumers' financial management. With the number of mobile banking users projected to surpass 3.6 billion globally by 2024, the adoption of these apps continues to rise. As more people rely on mobile banking, securing these applications is an urgent priority for financial institutions.

However, the average mobile banking app incorporates around 30 third-party libraries. This adds further complexity and security challenges that secure SDKs alone cannot address. Guardsquare recently released a mobile banking app security webinar focusing on why secure SDKs offer insufficient protection against growing threats.

In this article, we’ll explore the key takeaways of this webinar, including:

• The limitations of relying solely on secure SDKs
• Real examples of attacks of unprotected apps that use secure SDKs
• Insights into a holistic approach to mobile application protection

But first, let’s begin with why mobile banking apps need protection in the first place.

Why mobile banking apps need threat protection

Mobile banking apps handle sensitive information, including customers’ personal and financial data. This makes them prime targets for threat actors seeking to exploit vulnerabilities. Financial institutions are exposed to a variety of threats, including data breaches, unauthorized access to backend systems, and malicious app clones used in phishing attacks. These risks pose significant business threats, reinforcing the need for robust app security measures in mobile banking.

Beyond just protecting customer data, financial institutions must understand the importance of safeguarding their bank's internal operations. Cybercriminals often aim to infiltrate apps to gain access to confidential algorithms, banking information, and authentication data, leading to severe consequences for both the institution and its customers. Many banks implement secure SDKs as part of their defense response to such high stakes. While a logical first step, this is not enough to thwart an attack. We’ll explain below why secure SDKs alone are insufficient to cover all potential vulnerabilities, and why a more comprehensive approach is necessary.

What are secure SDKs?

SDKs are collections of third-party libraries and tools that developers use to build applications for specific platforms. These tools allow developers to add essential features to mobile apps—such as authentication, payment processing, or advertising—without having to create them from scratch. Secure SDKs, specifically, provide integrated security features to protect mobile applications from various threats, including reverse engineering or tampering. They are designed to follow best practices and adhere to development standards, ensuring that their internal operations are difficult for attackers to decipher or alter.

While secure SDKs are resilient against many forms of tampering and reverse engineering, the apps that use them are not foolproof. Several business needs and technical risks are not fully addressed by relying solely on secure SDKs, underscoring the need for a more comprehensive approach.

OWASP Mobile Top 10: A framework for understanding app security risks

The Open Web Application Security Project, or OWASP, is a non-profit dedicated to mobile and web app security. OWASP provides education and practical guidance to help mobile app developers achieve a stronger and more consistent security posture. This includes the OWASP Mobile Top 10, which outlines the most common security vulnerabilities found in mobile applications. Some examples covered are improper credential management, insecure data storage, and inadequate encryption.

When developers follow the OWASP Mobile Top 10 as a framework, it becomes clear how secure SDKs cannot mitigate all potential threats. One example is how a secure SDK might manage authentication. The SDK may protect against reverse engineering, in this instance. But, it may not prevent attackers from exploiting weaknesses in the app where the SDK is used.

The reason why it may not prevent attackers in this case is because the attacker can circumvent the information flow to the SDK. An attacker accomplishes this by altering input to the SDK or by tampering with communication between the app and external sensors, like a built-in mobile camera.

Case studies: Real-world examples of attacks

There are many different types of attacks on mobile banking apps. In many cases, secure SDKs are simply not enough to defend against these attacks. Below are three common real-world examples of how attackers can bypass or exploit gaps in the security of applications that use secure SDKs.

In this case study, an app used a secure SDK to implement facial recognition for user authentication. While the SDK was designed to prevent KYC attacks like fake video submissions (deepfakes), attackers bypassed the SDK by spoofing the device's sensor data. By feeding fake video input through the operating system, the attackers were able to trick the facial recognition system into authenticating an unauthorized user.

In another case, a bank in Southeast Asia used a secure SDK to protect its app from malware attacks. However, the attackers didn’t target the SDK directly. Instead, they tampered with the connection between the SDK and the app, disabling key security features and allowing malware to compromise the app. This illustrates how attackers can exploit the integration of an SDK into an app to weaken its security.

The third example comes from the PCI Mobile Point of Sale standard (MPOC), a security standard covering the use of mobile app and mobile devices as POS, also known as SoftPOS. While the standard allows for secure SDK integration, it does not excuse the rest of the application from meeting security requirements. Even in cases where the SDK isolates sensitive data, the application itself must still adhere to stringent security measures, highlighting the need for comprehensive application protection.

The importance of holistic mobile application protection

The overarching message is clear: secure SDKs are an important part of the security puzzle, but they are not enough on their own. To truly protect mobile banking apps, developers need to adopt a holistic approach to security that encompasses the entire application, not just isolated components.

Holistic protection involves securing the communication between the app, SDK, and external sensors, as well as hardening the app’s interaction with the operating system while ensuring that sensitive data is protected at every stage of the user journey. This approach makes it much harder for attackers to exploit any single point of weakness, as the entire application is safeguarded.

Guardsquare Product Manager Anton Baranenko stresses that protecting an app at the application level, rather than solely relying on SDKs, provides an additional layer of defense against attackers. By obscuring the boundaries between the app and the SDK, developers can create an opaque environment with multiple layers of defense that make it difficult for attackers to identify or exploit potential vulnerabilities.

Conclusion

As mobile banking continues its rapid growth, the need for strong app security has become more critical than ever. While secure SDKs offer protection against specific types of attacks, they alone do not provide a complete security solution. Never has it been more important to adopt a holistic approach to mobile app security by securing the entire application through multiple layers of defense - not just relying on the SDK.

To safeguard their apps against an increasingly sophisticated threat landscape, developers and financial institutions must learn and recognize the limitations of secure SDKs, as shown through real-world examples. This comprehensive approach ensures both external and internal vulnerabilities are addressed, enhancing the overall security posture of the app.