| M1 |
Improper Credential Usage: This vulnerability occurs when an application stores credentials like API keys, tokens, or passwords in an insecure manner, such as hardcoding them directly in the app's source code or configuration files. |
Use static analysis tools like MobSF to decompile the app and search for hardcoded API keys, tokens, and credentials in the source code. Use a proxy tool like Burp Suite to intercept network traffic and check for authentication credentials being sent in plaintext or weak formats. |
Do not embed or hardcode any credentials directly in the app. Utilize secure credential storage, such as a mobile key management service or platform-specific secure storage (e.g., Android Keystore, iOS Keychain). Implement server-side authentication with temporary, short-lived tokens. |
| M2 |
Inadequate Supply Chain Security: This refers to risks introduced by using third-party libraries, SDKs, or other components that may contain known vulnerabilities, outdated code, or malicious functionality. |
Use dependency scanning tools like Snyk or OWASP Dependency-Check to identify known vulnerabilities in third-party libraries and SDKs used in the app. Analyze the app's build process to ensure all dependencies are from trusted sources. |
Maintain a comprehensive Software Bill of Materials (SBOM) for the app. Regularly update all third-party libraries and dependencies to the latest, most secure versions. Vet all external components for known vulnerabilities before integration. |
| M3 |
Insecure Authentication/Authorization: This vulnerability involves flaws in how an application verifies user identity (authentication) or grants access to resources (authorization), allowing an attacker to bypass security controls and gain unauthorized access. |
Use a proxy tool like Burp Suite to manipulate authentication requests. Try to bypass the login process by replaying requests with a different user ID, or by using stolen/expired session tokens. Test for weak password policies, lack of MFA, and improper session management. |
Implement strong authentication policies, including multi-factor authentication (MFA) and account lockout after repeated failed login attempts. Ensure all authentication and authorization logic is performed on the server-side, and that sessions are properly managed and invalidated after a period of inactivity or on logout. |
| M4 |
Insufficient Input/Output Validation: This occurs when an application fails to properly validate, sanitize, or encode user-provided data, which can lead to injection attacks like SQL injection, command injection, or Cross-Site Scripting (XSS). |
Use a proxy tool like Burp Suite to modify input fields with common attack strings for SQL injection, command injection, and Cross-Site Scripting (XSS). Observe how the app and its backend handle these malicious inputs. Check for reflected or stored XSS vulnerabilities. |
Validate all user input on both the client and server side. Use parameterized queries for database interactions to prevent SQL injection. Sanitize and encode all output displayed in the app to prevent XSS and other injection attacks. |
| M5 |
Insecure Communication: This vulnerability arises from the failure to use encryption or from using weak encryption during data transmission between the mobile app and its server, making data susceptible to interception and eavesdropping. |
Use a proxy tool like Burp Suite to intercept network traffic. Check if the app is using HTTP instead of HTTPS. Analyze the TLS/SSL configuration to ensure a secure cipher suite is used. Test for Man-in-the-Middle (MITM) attacks to see if the app accepts insecure connections or fails to validate server certificates. |
Enforce the use of TLS/SSL for all network communication. Implement strong certificate pinning to prevent MITM attacks and ensure the app only communicates with trusted servers. Avoid allowing the app to accept self-signed or invalid certificates. |
| M6 |
Inadequate Privacy Controls: This issue is related to the app's failure to handle sensitive user data in a secure and compliant manner, such as storing personal information unencrypted or transmitting it to unauthorized third parties without user consent. |
Use a file system explorer on a rooted/jailbroken device to check for sensitive personal data (e.g., PII, health information) stored insecurely. Analyze network traffic with a proxy tool to see if private data is transmitted unencrypted or to unauthorized third-party services. |
Minimize the collection and storage of sensitive user data. Anonymize or encrypt all private data both in transit and at rest. Ensure data handling complies with privacy regulations like GDPR, HIPAA, and other country-specific laws. |
| M7 |
Insufficient Binary Protections: This involves a lack of security measures in the app's executable code, which can make it easy for attackers to reverse engineer, tamper with, or debug the app to discover its inner workings or bypass controls. |
Use dynamic analysis tools like Frida or Objection to test for and bypass security controls like root/jailbreak detection, debugger detection, or anti-tampering checks. Use a static analysis tool like MobSF to identify if the app binary has been obfuscated or protected against reverse engineering. |
Implement binary hardening techniques such as code obfuscation, anti-tampering, and anti-debugging. Use strong root/jailbreak detection and integrity checks to prevent the app from running on a compromised device. |
| M8 |
Security Misconfiguration: This occurs when the application or its underlying server and components are configured with insecure settings, such as having debug mode enabled in a production environment, or using default passwords for admin interfaces. |
Use a static analysis tool like MobSF to review the app's manifest file (e.g., AndroidManifest.xml) for insecure settings such as debuggable flags enabled in production, or public-facing components that shouldn't be. On the server side, check for open ports, default credentials, or directory listings. |
Adhere to secure configuration baselines. Disable debugging and other development-related features in production builds. Follow the principle of least privilege by ensuring all components have minimal permissions required to function. |
| M9 |
Insecure Data Storage: This vulnerability occurs when an application stores sensitive data on the mobile device's local storage in an unencrypted or easily accessible format, allowing attackers with physical access or a compromised device to retrieve it. |
Use a file system viewer on a rooted/jailbroken device to inspect the app's data directories. Look for sensitive data in databases (.db), shared preferences (.xml), or unencrypted files. Use a tool like SQLite Browser to open and inspect local databases. |
Avoid storing sensitive data on the device whenever possible. When necessary, use the platform's secure storage APIs (e.g., iOS Keychain, Android Keystore). Encrypt all sensitive data at rest using strong encryption algorithms. |
| M10 |
Insufficient Cryptography: This is the failure to use strong, modern, and well-vetted cryptographic algorithms to protect data. This includes using outdated or broken encryption methods, or implementing custom, flawed crypto logic. |
Use a static analysis tool like MobSF to identify the cryptographic algorithms used by the app. Use a proxy tool to analyze encrypted network traffic for weak or outdated cipher suites. Attempt to tamper with encrypted data to check for proper integrity checks. |
Use strong, industry-standard cryptographic algorithms (e.g., AES-256). Avoid implementing custom or homegrown cryptographic solutions. Ensure proper key management and secure key exchange. Do not use outdated or broken algorithms like MD5 or RC4. |
| New 1 |
Data Leakage: This occurs when sensitive information is unintentionally exposed and stored in insecure locations like logs, crash reports, or temporary files, making it accessible to other applications or attackers. |
Use a proxy tool like Burp Suite to capture all network traffic and analyze it for sensitive data being sent or received. On a rooted/jailbroken device, use a file system explorer to check log files (logcat for Android) and local storage for plaintext sensitive information. |
Avoid logging or storing any sensitive data on the device. Ensure that any temporary files are immediately and securely deleted after use. Use the device's secure storage mechanisms and encrypt data both at rest and in transit. |
| New 2 |
Hardcoded Secrets: This vulnerability involves embedding confidential information, such as API keys, cryptographic keys, or credentials, directly into the app's source code or configuration files. This allows attackers to easily extract them through reverse engineering. |
Use static analysis tools like MobSF or a decompiler like JADX to analyze the app's code. Search for hardcoded strings that look like API keys, URLs, or other secrets. Run the strings command on the app binary to quickly find plaintext strings. |
Do not hardcode secrets. Use a secure key management system, store credentials on a remote server, or leverage platform-specific secure storage (e.g., iOS Keychain, Android Keystore). |
| New 3 |
Insecure Access Control: This is a failure to properly restrict a user's access to certain functions or data. An attacker can exploit this to access information or perform actions they are not authorized for, either as a different user (horizontal privilege escalation) or as an administrator (vertical privilege escalation). |
Use a proxy tool like Burp Suite. Authenticate as a standard user, then try to access privileged endpoints or data by manually changing request parameters. Test for both horizontal (accessing another user's data by changing a user ID) and vertical (accessing an admin-only function) privilege escalation. |
Enforce strict access control rules on the server side for every request. Never rely on client-side checks for authorization. Implement the principle of least privilege, ensuring users can only access what is absolutely necessary for their role. |
| New 4 |
Path Overwrite and Path Traversal: This vulnerability allows an attacker to read or write files outside of the app's intended directory. It is often caused by insufficient validation of user input that includes file paths, allowing an attacker to use special characters like ../ to navigate the file system. |
Use a proxy tool like Burp Suite to inject path traversal sequences (../, ..\) into any user-controllable input that involves file operations, such as file uploads or image loading. Check if the app or server reads or writes files to an unintended location. |
Sanitize all user input related to file paths. Implement a strict allow-list of acceptable file names and paths. Use platform-specific file system APIs that are designed to prevent path traversal attacks. |
| New 5 |
Unprotected Endpoints: This vulnerability affects the app's components (like Android Activities, Services, or iOS Deeplinks) that can be invoked from other apps. If these components are not properly secured, a malicious app can call them and pass malicious data to compromise the application. |
Use static analysis tools like MobSF to review the app's manifest file and identify all exported components. On a test device, use tools like adb (for Android) to try and launch these components with malicious data to see if a crash or other unexpected behavior occurs. |
Ensure that app components are not exported unless absolutely necessary. When an endpoint must be exposed, protect it with proper permissions. Implement robust input validation and sanitization for any data received by these endpoints from external sources. |
| New 6 |
Unsafe Sharing: This vulnerability occurs when an application uses insecure methods for inter-app communication, which can lead to the unintended exposure of sensitive data to other applications on the same device. This often involves using insecure intents or content providers. |
Use dynamic analysis and a file system viewer on a rooted/jailbroken device to monitor data being passed between apps. Look for sensitive data being written to shared directories that are not properly secured or for broad intent filters that could be intercepted by other apps. |
Use explicit and secure intents for inter-app communication. When sharing sensitive data, use private Content Providers and enforce strict permissions to ensure only authorized applications can access the data. |
