Most application developers would consider the OWASP Mobile Top 10 a helpful planning resource for guiding their development efforts. It’s also helpful to take a look at its origins and evolution over time to understand what the list is communicating to developers today.
History / Origins
The non-profit OWASP foundation was founded on September 9, 2001 with the mission to improve the security of software. To help raise awareness of the need for more secure applications, the foundation published in 2003 the first OWASP Top Ten – a list of security threats for web applications. That list became a touchstone for application developers navigating different security threats. Most if not all of the items could be projected onto mobile applications, but it wasn’t designed to specifically address the unique threats posed by mobile applications. InQ3 2010, the OWASP foundation recognized the importance and unique security risks of mobile applications and began work on a Mobile Top 10. The first Mobile Top 10 was ultimately published in 2012. The goal of the initiative was simple – encourage the building of security into the mobile application development life cycle.
The Mobile Attack Surface - What Makes Mobile Applications Unique
The original OWASP Mobile TOP 10 took into account the unique threats facing mobile applications, including:
- Mobile device use cases – The mobile device has a great deal more information, such as SMS data and location data, because it is always on and always with its owner.
- Communication channels – Mobile applications need to secure communications across not just an Internet connection, but different transmission channels, including Wi-Fi, Bluetooth, SMS, and broadband carrier channels.
- Physical loss – A phone holds sensitive data and when lost poses a security risk.
The Latest OWASP Mobile Top 10
The OWASP Mobile Top 10 gives developers a list of application areas and threats that they should address in their software development process to make their software secure. The latest OWASP Mobile Top 10 was published in 2016 and includes the following threats:
- Improper Platform Usage – Misuse of a platform feature or failure to use platform security controls, such as platform permissions, the Keychain or TouchID.
- Insecure Data Storage – An attack on a lost or stolen mobile device or malware/software deployed on a mobile device.
- Insecure Communication – An attack on data being sent from the mobile device to the server as it traverses the carrier’s network and the Internet.
- Insecure Authentication – Automated service requests sent to the application’s back end to fake or bypass authentication. This usually involves malware or an attacker’s botnet.
- Insufficient Cryptography – Attacks to exposed APIs that lead to unencrypted or improperly encrypted data.
- Insecure Authorization – The use of stolen credentials to log in as a legitimate user. If there is over-privileged functionality, the attacker can destroy systems or access sensitive data.
- Client Code Quality – The ability for an attacker to remotely execute mobile code and pass untrusted inputs to method calls within mobile code. This can result foreign code execution or denials of service.
- Code Tampering – Attacks that change applications hosted in third-party app stores. Attackers may also trick users into downloading the modified applications via phishing campaigns.
- Reverse Engineering – Attacks that download a mobile application and reverse engineer the application using tools such as binary inspection tools so they can get information to attack back-end servers, modify the code, or steal intellectual property. Applications written in Java, .NET, Objective C, and Swift are particularly at risk for reverse engineering because they allow for dynamic introspection at runtime.
- Extraneous Functionality – Attackers that look at log files, configuration files and binaries to look for information that they can use to exploit backend servers.
Changes in Methodology
The original Mobile Top 10 list was simply derived by taking the most important mobile issues from the overall OWASP Top 10. Over time that methodology has evolved and in 2015-16 included the collection of application data from 14 different contributors and a survey of application developers. The 2016 list marked an important change in the Mobile Top 10. As you can see in the table, the list has morphed from a list of specific threats to broader categories of threats, which better represent the recommended focus areas for application developers. Also, the 2016 list has a greater emphasis on the mobile application itself, rather than the server. The list is evaluated periodically to see if it is still relevant or if there are important gaps in the list.
|M1||Insecure Data Storage||Weak Server-Side Controls||Improper Platform Usage|
|M2||Weak Server-Side Controls||Insecure Data Storage||Insecure Data Storage|
|M3||Insufficient Transport Layer Protection||Insufficient Transport Layer Protection||Insecure Communication|
|M4||Client-Side Injection||Unintended Data Leakage||Insecure Authentication|
|M5||Poor Authorization and Authentication||Poor Authorization and Authentication||Insufficient Cryptography|
|M6||Improper Session Handling||Broken Cryptography||Insecure Authorization|
|M7||Security Decisions Via Untrusted Inputs||Client-Side Injection||Client Code Quality|
|M8||Side Channel Data Leakage||Security Decisions Via Untrusted Inputs||Code Tampering|
|M9||Broken Cryptography||Improper Session Handling||Reverse Engineering|
|M10||Sensitive Information Disclosure||Lack of Binary Protections||Extraneous Functionality|
Mobile Top 10. New additions to the list in years 2014 and 2016 are highlighted.
The Impact on Developers
The original Mobile Top 10 was welcomed because it called out the specific security needs for mobile apps. That original list, however, now appears to be a smattering of issues as opposed to a comprehensive guide for developers. Today, the Mobile Top 10 still doesn’t provide all the answers, but it does give organizations a solid, comprehensive framework of threat categories around which they can focus their development efforts. I expect future releases of the list to continue to provide a broad-based and prescriptive guide for building secure applications.