Software:Mobile application security

From HandWiki
Short description: mobile application security


Mobile application security (mobile AppSec) is the discipline of protecting mobile apps, the data, and backend services they connect to from reverse engineering, tampering, malware, and runtime attacks across an app's development lifecycle. It sits between two broader fields: application security, which covers building and verifying secure software generally, and mobile security, which covers protecting the device, operating system, and network layers a mobile app runs on. Mobile application security narrows that scope to the app itself. It focuses on the compiled binary sitting on a device the developer does not control, along with the code and secrets packaged inside it.

Standards bodies and industry analysts publish guidance specifically addressing mobile application security, distinguishing it from broader application security and mobile security concerns. The Open Worldwide Application Security Project (OWASP) maintains "OWASP Mobile Application Security" as a separate dedicated project from its general Application Security Verification Standard (ASVS), on the grounds that mobile apps raise concerns, such as binary exposure and reverse engineering, that its web-focused standards do not fully address.[1] Gartner has similarly tracked "mobile application security testing" as a distinct technology category in its Hype Cycle for Application Security, along with Application Shielding. The analyst firm has published a dedicated market guide for it, separate from its general application security testing and mobile device management coverage.[2]

This distinction matters in practice because a mobile app, unlike a server-side web application, ships an executable copy of itself onto a device that is fully accessible to an attacker. The attacker can install the app, decompile it, attach a debugger, run it on an emulator, or modify and repackage it, without ever touching the developer's own infrastructure. Mobile application security therefore largely focuses on defending against this class of client-side attacks, on top of the concerns it already shares with web and API security, such as insecure data storage, weak authentication, and insufficient transport-layer protection.

Overview

Smartphones are used to access sensitive personal and financial information, including banking and payment services, as well as enterprise systems and data.[3] That has made mobile apps a target. Attackers steal credentials and payment data, extract and run fraud at scale through farmed emulators and automated bots, or take a legitimate app, repackage it with malicious code, and redistribute it. Academic work on mobile malware traced reverse engineering, tampering, and repackaging as recurring attack methods more than a decade ago;[4] mobile app security vendors have continued to report the same categories, along with API exploitation, as ongoing attack vectors.[5]

Mobile application security is usually treated as spanning the entire software development life cycle, from secure design and coding through automated testing in continuous integration pipelines to hardening release binaries and monitoring apps once they reach stores such as the Google Play Store and the Apple App Store. Once an app is published, the developer has limited visibility into how it is used or attacked after it leaves the build pipeline, unless the app is built to report threat telemetry back.

Why mobile apps require dedicated security practices

Several properties of the mobile environment set app security apart from traditional web or server application security.

  • The client is untrusted and physically exposed. A mobile app binary can run on a device the attacker controls, so decompilers, disassemblers, and static analysis tools can be pointed directly at the compiled code. An attacker can read an app's logic, extract embedded API keys and cryptographic material from the binary, and reverse-engineer its business logic without ever touching a server.
  • The binary itself can be patched and redistributed. Because the application binary is under the attacker's control, the app can be repackaged and republished under a different name, for example, to strip out license checks, bypass in-app purchases, inject malware, or intercept and alter data before it reaches the server. Academic literature has documented repackaging and cloning Android apps as a distinct malware-distribution route.[6]
  • The runtime environment is hostile by design. On a rooted or jailbroken device, or inside an emulator, debugger, or dynamic instrumentation framework, an attacker can watch and modify an app's behavior while it runs, even where the code itself resists static analysis.
  • Distribution and the device population are both harder to control than on the desktop. Apps are typically installed through official stores but can equally be sideloaded from third-party marketplaces or direct downloads, and the resulting devices span a wide range of OS versions, manufacturers, and hardware capabilities, such as whether a hardware-backed secure element is present, in a way that a single web server environment does not have to contend with.
  • Resources are constrained. Mobile devices have far less battery life, memory, and processing power than servers, and users notice when an app is slow or large, so security controls have to be engineered with performance and app size in mind.

Many standard web application security controls, discussed at greater length in application security, still apply to a mobile app's backend and API layer. On their own, though, they are not sufficient; the client binary needs its own layer of defense. For device- and network-level risks, a mobile app inherits them simply by running on a phone, such as SIM-based attacks, Bluetooth exploits, or rogue Wi-Fi access points; see mobile security.

The mobile application security lifecycle

Mobile AppSec practices are usually mapped across the phases of app development and its life after release, extending the general application-security lifecycle described in the application security article.

  • Design and requirements. Threat modeling for mobile-specific risks, such as what happens if a device is rooted, an API key is extracted, or backend API endpoints are exposed.
  • Development. Secure coding practices, secure API communications (such as certificate pinning and short-lived tokens), and platform-provided secure storage (such as the Android Keystore system and the Apple Keychain), while avoiding hardcoded secrets.
  • Build and integration. Automated security testing built into the pipeline, with code-hardening protections applied as part of the release build.
  • Pre-release testing. Static application security testing (SAST), Dynamic application security testing (DAST), Interactive application security testing (IAST), and manual penetration testing of the compiled binary before submission to an app store.
  • Post-release monitoring. Detecting threats against apps already installed on user devices, including counterfeit or modified copies circulating outside official stores, since a published app cannot be patched instantly the way a server can.

Common threats and attack techniques

For threats that target the underlying device, operating system, or radio/network stack, as opposed to a specific app, such as SS7 and IMSI-catcher attacks, Bluetooth exploits, or malicious firmware, see mobile security. The list below is specific to the app binary and its own network and storage behavior.

  • Reverse engineering. Decompiling or disassembling an app to read its source logic, extract algorithms, or find embedded secrets.
  • Repackaging and code tampering. Modifying a decompiled app, for example, to bypass license checks, remove ads, inject malware, or redirect payments, then redistributing it, often through unofficial app stores.[6]
  • Dynamic instrumentation and hooking. Intercepting, inspecting, or modifying an app's behavior at runtime, including bypassing certificate pinning, root/jailbreak detection, or authentication checks.
  • Man-in-the-middle attacks against app traffic. Intercepting network traffic between the app and its backend, typically over insecure or compromised Wi-Fi, to read or alter data in transit.
  • Insecure data storage. Tokens, credentials, or personal data left unencrypted in local storage, logs, backups, or caches, recoverable by an attacker with physical or malware access to the device.
  • API and backend abuse. Since many mobile apps are thin clients for a backend API, attackers often find API weaknesses by first reverse-engineering the mobile client to see how it talks to the server.
  • Malicious and cloned apps. Fake or trojanized versions of legitimate apps built by repackaging a genuine app with malicious code, then distributed to trick users into installing them.
  • Emulator and bot abuse. Running an app inside an emulator or automation framework, or directing an AI agent, at scale to commit fraud, such as fake account creation, credential stuffing, or abuse of promotions and loyalty programs. This kind of automated abuse increasingly targets a mobile app's backend API directly, bypassing the app's own interface since APIs are built for automation and often expose more functionality than the UI does.
  • Supply chain risk. Vulnerabilities introduced through third-party SDKs, open-source libraries, or compromised build tooling, as distinct from vulnerabilities in the app's own first-party code.

OWASP Mobile Top 10 (2024)

The OWASP Foundation's Mobile Top 10 project publishes a periodically updated list of the most critical mobile application security risks, based on incident reports, vulnerability data, and expert review.[7] The 2024 revision lists:

  1. M1: Improper Credential Usage
  2. M2: Inadequate Supply Chain Security
  3. M3: Insecure Authentication/Authorization
  4. M4: Insufficient Input/Output Validation
  5. M5: Insecure Communication
  6. M6: Inadequate Privacy Controls
  7. M7: Insufficient Binary Protections
  8. M8: Security Misconfiguration
  9. M9: Insecure Data Storage
  10. M10: Insufficient Cryptography

Compared with the 2016 list, the 2024 revision adds supply chain security and binary protection as distinct top-level categories, reflecting the growing prominence of reverse engineering, tampering, and third-party dependency risk in reported incidents.[7] OWASP maintains two closely related mobile projects alongside the Top 10 list. The Mobile Application Security Verification Standard (MASVS) sets out security requirements for mobile apps, used by architects and developers as a foundational requirement and by testers as a benchmark.[8] The Mobile Application Security Testing Guide (MASTG) is a detailed manual of testing techniques and test cases aligned with the MASVS, covering static and dynamic analysis and reverse-engineering methodology for iOS and Android.[9]

Core defensive domains

OWASP's MASVS groups app-level security requirements into several categories, including storage, cryptography, authentication, network communication, platform interaction, code quality, privacy, and resilience.[8] Most of what the security industry calls "mobile app protection" falls under the resilience category specifically, since it addresses reverse engineering and tampering rather than the more general engineering concerns covered elsewhere in MASVS.[10]

Secure development and code quality

Standard practices include avoiding hardcoded secrets, validating input and output, using platform-provided secure storage APIs, and enforcing certificate pinning for network calls. Apple and Google have published secure coding guidance for Android[11] and iOS[12] app development, as well as for cross-platform frameworks such as React Native and Flutter.

Resilience: hardening, runtime self-protection, and attestation

OWASP's MASVS-RESILIENCE category covers a cluster of related techniques aimed at making an app harder to reverse engineer or tamper with, rather than a single technique.[10]

Code obfuscation is one component, an application of the general concept of software obfuscation to mobile binaries. Common techniques include:

  • Name obfuscation and code shrinking rename classes, methods, and fields using meaningless identifiers and remove unused code. On Android, Google's open-source R8 compiler has been the default code shrinker and obfuscator in the Android Gradle Plugin since 2019 and remains compatible with existing ProGuard configuration rules.
  • Control-flow obfuscation, which restructures an app's logic so its execution flow is hard to follow even with a decompiler.
  • String and resource encryption, so embedded secrets cannot simply be read out of the binary.
  • Polymorphic protection, which varies the obfuscation applied between builds so a technique that worked against one release does not automatically work against the next.

A second component is runtime application self-protection (RASP): defenses built into the app itself that detect and react to hostile conditions while it is running, on top of whatever protections were applied at build time. Common checks include rooted or jailbroken devices, debuggers, emulators, dynamic hooking frameworks, tampering with the app's code signing or checksum, and execution in an unexpected or repackaged environment. Depending on what it finds, an app can log and alert, restrict its functionality, or shut down.

A third component is app attestation: platform features such as Google's Play Integrity API[13] and Apple's DeviceCheck and App Attest services[14] provide baseline OS-level checks that let a backend server cryptographically check that a request comes from an unmodified copy of the app running on a real device, helping rule out emulators, patched binaries, and automated bots. In defense-in-depth security architectures, these platform baselines are frequently complemented by additional runtime checks and monitoring to address broader threat vectors.

OWASP's own MASVS documentation frames these resilience controls as defense-in-depth measures that sit alongside sound security architecture, never in place of it. The absence of obfuscation or anti-tampering does not by itself constitute a vulnerability, and OWASP states directly that such techniques "must not be used as a substitute for proper security architecture." The same documentation also notes that resilience measures can reduce the transparency of what a compiled app is doing and make independent code review harder, which is a particular concern for apps in public-interest sectors such as government or health.

Testing

Gartner defines mobile application security testing as covering static, dynamic, and behavioral analysis of an app before or after development.[2] Applied to mobile apps specifically, static and dynamic techniques are adapted as discussed in more detail in Testing methodologies below; behavioral testing observes an app's runtime behavior for signs of abuse rather than checking it against a fixed rule set.

Post-release monitoring

Once an app is published, its security is no longer only a pre-release concern. Ongoing visibility into how it is being attacked or abused, for example through counterfeit or repackaged copies circulating outside official stores, unusual traffic suggesting bot or fraud activity, or attacks attempted against instrumented apps on real user devices, functions as a further layer of defense, since a shipped mobile binary cannot be patched the instant a new attack technique surfaces the way a server usually can.

Testing methodologies

Mobile app security testing draws on the same broad categories as general application security, static application security testing (SAST), dynamic application security testing (DAST), interactive application security testing (IAST), and software composition analysis (SCA). Applied to mobile apps, each is adapted somewhat. SAST tools work against decompiled or disassembled mobile binaries. Because there is no server-side source code to inspect, they look for issues such as hardcoded secrets, insecure API usage, and insufficient obfuscation directly in the compiled app. DAST tools exercise a running app on an emulator or physical device, observing network calls, local data storage, and platform API usage. Unlike a single-server environment, mobile DAST must account for a wide range of OS versions and device models. IAST tools instrument the app runtime during automated or manual testing to identify vulnerabilities while code executes in real time. SCA flags known-vulnerable third-party mobile SDKs against public vulnerability databases such as Common Vulnerabilities and Exposures (CVE). Manual penetration testing and reverse engineering, following methodologies such as the OWASP MASTG, still catch logic flaws and bypasses that automated tools miss. This kind of testing is commonly integrated into continuous integration pipelines to evaluate builds on each commit, well before a periodic audit would catch the same problem.[9]

Standards, frameworks, and regulation

Mobile application security is shaped by open community standards alongside formal regulatory requirements.

  • OWASP's MASVS and MASTG open standard and testing methodologies specific to mobile apps.[8][9]
  • NIST guidance, including Special Publication 800-124 Revision 1, Guidelines for Managing the Security of Mobile Devices in the Enterprise.[15]
  • The Payment Card Industry Data Security Standard (PCI DSS), which applies to apps handling payment card data and mandates secure development, vulnerability management, and protection of client-side code.[16]
  • The Health Insurance Portability and Accountability Act (HIPAA), which applies to apps handling protected health information in the United States and requires technical safeguards against unauthorized access.[17]
  • Data protection regulations such as the European Union's General Data Protection Regulation (GDPR) govern what data an app collects, how it is stored, and user consent.[18][19] This overlaps with the "Inadequate Privacy Controls" category in the OWASP Mobile Top 10.[20]
  • Platform requirements set directly by Apple and Google through their app store review guidelines,[21][22] which define mandatory baseline security and privacy requirements for published apps.

Industry and tooling

Several companies sell commercial tools in the domains above spanning mobile application security testing, app shielding, code hardening, runtime application self-protection (RASP), and app attestation.

The OWASP Foundation remains a vendor-neutral nonprofit and does not endorse any of the companies that build tools against its standards. It recognizes organizations as "MAS Advocates" for their sustained contributions to the Mobile Application Security Verification Standard (MASVS) and Mobile Application Security Testing Guide (MASTG).[1]

Standard guidance and baseline controls

Industry guidance published by the OWASP Foundation and NIST outlines common baseline controls for mobile application security:[8][9][15]

  • Client-side threat modeling: Frameworks emphasize evaluating risks specific to the client binary, such as reverse engineering or device compromise, alongside traditional server and API risks.
  • Credential and secret management: Published standards advise against hardcoding API keys or cryptographic secrets in code, recommending platform secure-storage features (like Android Keystore and Apple Keychain) and short-lived tokens instead.
  • Code hardening: Guidance recommends applying obfuscation and protection mechanisms to release builds, varying techniques between releases to prevent repeated exploitation.
  • Network transport security: Standards call for Transport Layer Security (TLS) coupled with certificate or public-key pinning to protect communication channels.
  • Runtime environmental checks: Security baselines include controls that detect rooted or jailbroken operating systems, active debuggers, emulators, and dynamic instrumentation tools.
  • Platform attestation: Architectural recommendations incorporate platform attestation APIs to verify binary and device integrity before fulfilling backend requests.
  • Automated pipeline testing: Frameworks advise integrating automated security scanning into continuous integration pipelines rather than relying solely on periodic manual audits.
  • Post-release threat visibility: Guidance highlights the need for ongoing monitoring of repackaged binaries and anomalous traffic patterns following publication.
  • Dependency management: Standards emphasize continuous vetting of third-party SDKs and open-source libraries to mitigate supply chain risks.

OWASP's own guidance notes that while hardening and resilience measures provide critical defense-in-depth, they serve to complement rather than replace secure underlying software architecture.[10]

See also

References

  1. ↑ 1.0 1.1 "Introduction to the OWASP Mobile Application Security Project - OWASP Mobile Application Security". https://mas.owasp.org/MASTG/0x03-Overview/. 
  2. ↑ 2.0 2.1 Marketing, Keith Mokris, NowSecure (2017-04-27). "Gartner Mobile Application Security Testing Guide" (in en-US). https://www.nowsecure.com/blog/2017/04/27/gartner-market-guide-for-mobile-application-security-testing/. 
  3. ↑ Howell, Gema (2023-05-17). "Guidelines for Managing the Security of Mobile Devices in the Enterprise" (in en). https://csrc.nist.gov/pubs/sp/800/124/r2/final. 
  4. ↑ Suarez-Tangil, Guillermo; Tapiador, Juan E.; Peris-Lopez, Pedro; Ribagorda, Arturo (2014). "Evolution, Detection and Analysis of Malware for Smart Devices". IEEE Communications Surveys & Tutorials. 16 (2): 961–987.
  5. ↑ "Application Security Report 2024 | Akamai" (in en-US). https://www.akamai.com/resources/state-of-the-internet/securing-apps-report-2024. 
  6. ↑ 6.0 6.1 Crussell, Johnathan; Gibler, Clint; Chen, Hao (2012). "Attack of the Clones: Detecting Cloned Applications on Android Markets". University of California, Davis. http://web.cs.ucdavis.edu/~hchen/paper/esorics2012.pdf
  7. ↑ 7.0 7.1 Foundation, OWASP. "OWASP Mobile Top 10" (in en). https://owasp.org/projects/mobile-top-10. 
  8. ↑ 8.0 8.1 8.2 8.3 "OWASP MASVS - OWASP Mobile Application Security". https://mas.owasp.org/MASVS/. 
  9. ↑ 9.0 9.1 9.2 9.3 "OWASP MASTG - OWASP Mobile Application Security". https://mas.owasp.org/MASTG/. 
  10. ↑ 10.0 10.1 10.2 "MASVS-RESILIENCE: Resilience Against Reverse Engineering and Tampering - OWASP Mobile Application Security". https://mas.owasp.org/MASVS/11-MASVS-RESILIENCE/. 
  11. ↑ "Privacy checklist" (in en). https://developer.android.com/privacy-and-security/about. 
  12. ↑ "Security" (in en-US). https://developer.apple.com/documentation/security. 
  13. ↑ "Play Integrity API" (in en). https://developer.android.com/google/play/integrity. 
  14. ↑ "DeviceCheck" (in en-US). https://developer.apple.com/documentation/devicecheck. 
  15. ↑ 15.0 15.1 Souppaya, Murugiah P.; Scarfone, Karen (2013-06-21) (in en). Guidelines for Managing the Security of Mobile Devices in the Enterprise (Report). Gaithersburg, MD: National Institute of Standards and Technology. doi:10.6028/NIST.SP.800-124r1. https://www.nist.gov/publications/guidelines-managing-security-mobile-devices-enterprise. 
  16. ↑ "Document Library" (in en-US). https://www.pcisecuritystandards.org/document_library/. 
  17. ↑ U.S. Department of Health and Human Services, "HIPAA Security Series". https://www.hhs.gov/sites/default/files/ocr/privacy/hipaa/administrative/securityrule/techsafeguards.pdf
  18. ↑ European Union, Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data (General Data Protection Regulation), OJ L 119, 4 May 2016, pp. 1–88; see in particular Articles 5, 6, 7, 25 and 32.
  19. ↑ Commission nationale de l'informatique et des libertés (CNIL), "Recommandation relative aux applications mobiles", Délibération no. 2024-061 of 18 July 2024.
  20. ↑ OWASP Foundation, "M6: Inadequate Privacy Controls", OWASP Mobile Top 10, 2024 release. https://owasp.github.io/www-project-mobile-top-10/2023-risks/m6-inadequate-privacy-controls
  21. ↑ "App Review Guidelines" (in en). https://developer.apple.com/app-store/review/guidelines/. 
  22. ↑ "Android Apps on Google Play" (in en-US). https://play.google.com/store/games/?hl=en_US. 
Retrieved from "https://handwiki.org/wiki/index.php?title=Software:Mobile_application_security&oldid=4663629"