OWASP Top 10 for Mobile: All You Need to Know

It’s not surprising to hear that with 45% of the world’s population owning a smartphone, attacks on mobile devices are on the rise. Every CISO or employee in cybersecurity has at least once heard of the OWASP Top 10 List of Application Security Risks, but some do not know that OWASP has also set out to create several companion projects as the new application threat edges emerge: Mobile, API, Serverless, etc. All of the Top 10 lists are updated and reissued periodically.

The rankings are not in sequential order. Rather, they represent just a list of trending top issues.

In this blog post, we will focus on the OWASP list dedicated to mobile application use cases: OWASP Top 10 – Mobile. 

OWASP Mobile Top 10 – overview

The mobile Top 10 list items are labeled M1-M10 and are similar in character to their web application counterparts but optimized for mobile experiences. 

The Mobile Top 10 helps enumerate common vulnerabilities based on the particulars and nuances of mobile environments: OS, hardware platforms, security schemas, execution engines, etc. Each vulnerability type is discussed and defined on the OWASP website but it does not take much of a developer to recognize the basic forms of a given Top 10 element.

M1 – Improper Platform Usage

Misuse or failure to use basic, platform dev guidelines, security features, and common conventions. That could be key storage, liberal or lax permissions, poorly engineered use of device biometric controls, etc. 

M2 – Insecure Data Storage

This concerns protections for “data at rest” (or weaknesses). It is a threat for rogue apps or a lost device that has unprotected data at rest to be viewed, sniffed, or cracked.

M3 – Insecure Communication

This concerns “data in transit” protections (or weaknesses). Many mobile apps fit well into client-server models and many threat analyses will make sense here. Data could be defined as an audio or video stream (call and facetime tapping) as well as “traditional” data streams. There are multiple channels (“physical layers”) as well: an IP-type channel in addition to the RF-based voice and data channels. 

M4 – Insecure Authentication

Authentication is the check to see that you are who you say you are. This can be hacked via credential stuffing and session hijacking. Mobile use cases and UI/UX seem to favor shorter passwords/pins and biometric controls with an underlying assumption that the device is always under the primary user/owners’ control, but that is simply very often not the case.

M5 – Insufficient Cryptography

With the existence of commonly-used cryptographic algorithms, like SHA-1 and MD4/5, and widespread knowledge of the importance of encryption, it is questionable how this threat is still so high on the list. 

M6 – Insecure Authorization

With respect to mobile specifically, this is commonly talked about when an app on your phone wants access to everything on your phone, such as a game wanting access to your contacts, or a Snapchat-type app wanting access to your GPS, contacts, and keychain. Some authorization requests may make sense, but for many apps, you may not want to give them complete access to everything on your phone. 

M7 – Client Code Quality

This is what most of us think of as AppSec (but hopefully you are detecting that AppSec and DevSecOps are MUCH more than this). All the application security testing lives here. This is a very deep and very developer-heavy topic but fortunately, there are things like Kiuwan to help.

M8 – Code Tampering

This is a cousin to Supply Chain weakness and covers things like reverse engineering your app to allow it to be manipulated into alternate use cases. It also includes malware (Google Play and Apple App Store) and root-kitted devices. This specific class of issues will enjoy a long and persistent/pernicious run on the Mobile T10 (and IoT and any use case that doesn’t have a strong DevOps-CI/CD refresh component).

M9 – Reverse Engineering

In the future, this may become part of everything else on the list. You have seen this in “M8-Code Tampering.” You may have controls in place via DevOps (Assembla, Git, etc.) and physical security/data exfiltration programs (cleared workspaces, NDA’s, policies, etc.). You will talk about it in Supply Chain meetings. At some level, in some form, it is a precursor or fundamental starting point for all exploit and vulnerability efforts. Maybe not a deep code review, but at some level, the “bad guys” will be looking at your work in a black/white/grey box type of way.

M10 – Extraneous Functionality

Think the principle of least privilege here. Lock down and deny access to everything except what is absolutely and minimally needed to get the job done. This one will probably be known to you as developers’ back doors (walk through walls cheats) or maybe security controls bypass (SE Linux OFF type things), chatty logs, or port 22/23 up, that accidentally get left in production builds.

OWASP and Kiuwan

Kiuwan has long been a fan and supporter of OWASP (Open Web Application Security Project) and our SAST product (Kiuwan Code Security) scans source code looking for code patterns that indicate vulnerabilities such as those on the OWASP Top 10 list (as well as deeper quality issues – remember M7 above, OWAP Webapp T10 and other standards). Kiuwan can’t solve every one of the Mobile Top 10 issues, but we do help developers understand where to look in their source code. Organizations use Kiuwan to help identify and manage risks (Mobile T10 in this case) in their source code. 

If you want to try out first-hand a SAST and an SCA tool, contact our sales team today to request a trial of Kiuwan.