What are OWASP Mobile Top 10?

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.

Each vulnerability type is investigated and explained on the OWASP website yet even a beginner developer may recognise the fundamental forms of a Top 10 element — **OWASP Mobile Top 10**

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.

OWASP Mobile Top 10 M1 Basic platform development principles security features and common conventions are either neglected or misused

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.

OWASP Mobile Top 10 M2 This is about security for data at rest or weaknesses Rogue programmes or a lost device with unencrypted data in transit can be read sniffed or decrypted

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.

OWASP Mobile Top 10 M3 Many mobile apps are well suited to client server architectures and many threat assessments make sense in this setting Data can be in the form of audio or video streams as well as traditional data streams

M4-Insecure Authentication

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.

OWASP Mobile Top 10 M4 Authentication is the process of confirming that the person you claim to be is who you say you are To breach into this system credential stuffing and session hijacking can be employed

M5-Insufficient Cryptography

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.

OWASP Mobile Top 10 M5 It's difficult to understand why this issue is still so high on the priority list, given the widespread use of cryptographic algorithms like SHA-1 and MD4/5 and general understanding of the need of encryption.

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.

OWASP Mobile Top 10 M6 While authorization queries are acceptable you may not want to give many apps complete 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.

OWASP Mobile Top 10 M7 Buffer overflows format string vulnerabilities and a number of other code level issues allow code to run on mobile devices are examples of vulnerabilities in this category

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.

OWASP Mobile Top 10 M8 This is a close cousin of Supply Chain Weakness and it entails things like reverse engineering your programme so that it may be updated for diverse use cases Malware such as root kitted devices and tampered Google Play and Apple App Stores are also included — ]

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.

OWASP Mobile Top 10 M9 In the future reverse engineering may become a part of everything else on the list M8 Code Tampering discussed this Physical securitydata exfiltration programmes authorised workspaces NDAs policies etc and DevOps Assembla Git etc may be in place

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.