M1-M10 are the mobile Top 10 list items, which are comparable to their online application counterparts but optimized for mobile experiences.
The Mobile Top 10 assists in the identification of common vulnerabilities in mobile environments, such as operating systems, hardware platforms, security schemas, execution engines, and so on. On the OWASP website, each vulnerability type is examined and detailed, although even a novice developer may detect the basic forms of a specific Top 10 element.
The OWASP Mobile Top 10 chart evolves over time.
M1 – Improper Platform Usage
Basic platform development rules, security features, and common conventions are misused or ignored. This could include key storage, permissive or restrictive permissions, poorly designed device biometric controls, and so on.
M2 – Insecure Data Storage
This is about “data at rest” protections (or weaknesses). Rogue programmes or a lost device with unsecured data at rest pose a hazard to be viewed, sniffed, or cracked.
M3 – Insecure Communication
This is about protections for “data in transit.” Many mobile apps are well-suited to client-server architectures, and many threat evaluations will make sense in this context. Audio or video streams, as well as “conventional” data streams, are examples of data. In addition to the RF-based speech and data channels, there are several channels (“physical layers”) and an IP-type channel.
Authentication is the process of verifying that you are who you claim to be. Credential stuffing and session hijacking can be used to break into this system. Shorter passwords/pins and biometric controls appear to be preferred in mobile use cases and UI/UX, with the underlying assumption that the device is always under the primary user/owners’ control, which is rarely the case.
With widely used cryptographic algorithms like SHA-1 and MD4/5 and widespread awareness of the importance of encryption, it’s hard to understand why this issue is still so high on the priority list.
M6- Insecure Authorization
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-like app demanding access to your GPS, contacts, and keychain, this is usually referred to as “app permissions.” Some authorization requests are reasonable, but for many apps, you may not want to provide them full access to your phone.
M7-Client Code Quality
Vulnerabilities in this category include buffer overflows, format string vulnerabilities, and a variety of other code-level errors that allow code to run on mobile devices. For example, in the event of a buffer overflow, it is possible to write into places known to contain executable code and replace it with malicious code, or to selectively overwrite data relevant to the program’s state, resulting in behaviour not intended by the original programmer. The majority of coding bugs may be resolved by following best practises. To mitigate this risk, having code patterns that are easy to read and come with comprehensive documentation across your business is a smart place to start.
M8 – Code Tampering
A close relative of Supply Chain Weakness, and it includes things like reverse engineering your software to allow it to be modified into different use cases. Malware like (Tampered Google Play and Apple App Store) and root-kitted devices are also included. On the Mobile T10 (and IoT, and any use case that doesn’t have a significant DevOps-CI/CD refresh component), this exact class of bugs will have a long and pernicious run.
M9- Reverse Engineering
Reverse Engineering may become a part of everything else on the list in the future. This was covered in “M8-Code Tampering.” DevOps (Assembla, Git, etc.) and physical security/data exfiltration programmes (approved workspaces, NDAs, policies, etc.) may be in place. It will be discussed in Supply Chain meetings. It is a predecessor or fundamental beginning point for all exploit and vulnerability efforts on some level, in some manner. Perhaps not a detailed code review, but the “bad guys” will be looking at your work in a black/white/grey box fashion at some point.
M10 – Extraneous Functionality
Consider the concept of least privilege in this situation. Everything except what is absolutely and minimally required to complete the task should be locked down and denied access. Developers’ back doors, security controls bypass, chatty logs, or port 22/23 up are all examples of items that get mistakenly left in production builds.
Read more cybersecurity blogs