The rules are aligned with the version 1.5.0 of the OWASP MASTG. While complete coverage of all tests cannot be guaranteed, the authors have made significant efforts to provide a comprehensive overview of the status of each implemented rule.
The presence of False Positives (FP) is expected but limited and efforts have been done to reduce the potential occurrence of False Negatives (FN).
The grade of maturity and the reliability of each rule has been classified according to the following categories:
✔️ Complete: the rule is highly reliable, although there may be some false positives.
👍 Good: the rule is reliable but there may be false negatives.
💔 Partial: the rule does not sufficiently cover all static tests.
😅 Tentative: the rule is based on a generous simplification of the static tests.
❌ Infeasible: the rule can not be implemented with the current free version of Semgrep.
| MASVS-ID | Requirement | L1/L2/R | Status | |
|---|---|---|---|---|
| MSTG-ARCH-9 | A mechanism for enforcing updates of the mobile app exists. | L2 | Good | 👍 |
| MSTG-STORAGE-1 | System credential storage facilities need to be used to store sensitive data, such as PII, user credentials or cryptographic keys. | L1 | Partial | 💔 |
| MSTG-STORAGE-2 | No sensitive data should be stored outside of the app container or system credential storage facilities. | L1 | Good | 👍 |
| MSTG-STORAGE-3 | No sensitive data is written to application logs. | L1 | Good | 👍 |
| MSTG-STORAGE-4 | No sensitive data is shared with third parties unless it is a necessary part of the architecture. | L1 | Infeasible | ❌ |
| MSTG-STORAGE-5 | The keyboard cache is disabled on text inputs that process sensitive data. | L1 | Good | 👍 |
| MSTG-STORAGE-6 | No sensitive data is exposed via IPC mechanisms. | L1 | Tentative | 😅 |
| MSTG-STORAGE-7 | No sensitive data, such as passwords or pins, is exposed through the user interface. | L1 | Good | 👍 |
| MSTG-STORAGE-8 | No sensitive data is included in backups generated by the mobile operating system. | L2 | Good | 👍 |
| MSTG-STORAGE-9 | The app removes sensitive data from views when moved to the background. | L2 | Complete | ✔️ |
| MSTG-STORAGE-10 | The app does not hold sensitive data in memory longer than necessary, and memory is cleared explicitly after use. | L2 | Infeasible | ❌ |
| MSTG-STORAGE-11 | The app enforces a minimum device-access-security policy, such as requiring the user to set a device passcode. | L2 | Tentative | 😅 |
| MSTG-CRYPTO-1 | The app does not rely on symmetric cryptography with hardcoded keys as a sole method of encryption. | L1 | Good | 👍 |
| MSTG-CRYPTO-2 | The app uses proven implementations of cryptographic primitives. | L1 | Good | 👍 |
| MSTG-CRYPTO-3 | The app uses cryptographic primitives that are appropriate for the particular use-case, configured with parameters that adhere to industry best practices. | L1 | Infeasible | ❌ |
| MSTG-CRYPTO-4 | The app does not use cryptographic protocols or algorithms that are widely considered deprecated for security purposes. | L1 | Partial | 💔 |
| MSTG-CRYPTO-5 | The app doesn't re-use the same cryptographic key for multiple purposes. | L1 | Infeasible | ❌ |
| MSTG-CRYPTO-6 | All random values are generated using a sufficiently secure random number generator. | L1 | Partial | 💔 |
| MSTG-AUTH-1 | If the app provides users access to a remote service, some form of authentication, such as username/password authentication, is performed at the remote endpoint. | L1 | Infeasible | ❌ |
| MSTG-AUTH-8 | Biometric authentication, if any, is not event-bound (i.e. using an API that simply returns "true" or "false"). Instead, it is based on unlocking the keychain/keystore. | L2 | Good | 👍 |
| MSTG-NETWORK-1 | Data is encrypted on the network using TLS. The secure channel is used consistently throughout the app. | L1 | Partial | 💔 |
| MSTG-NETWORK-2 | The TLS settings are in line with current best practices, or as close as possible if the mobile operating system does not support the recommended standards. | L1 | Complete | ✔️ |
| MSTG-NETWORK-3 | The app verifies the X.509 certificate of the remote endpoint when the secure channel is established. Only certificates signed by a trusted CA are accepted. | L1 | Soon... | 🕓 |
| MSTG-NETWORK-4 | The app either uses its own certificate store, or pins the endpoint certificate or public key, and subsequently does not establish connections with endpoints that offer a different certificate or key, even if signed by a trusted CA. | L2 | Partial | 💔 |
| MSTG-NETWORK-6 | The app only depends on up-to-date connectivity and security libraries. | L2 | Infeasible | ❌ |
| MSTG-PLATFORM-1 | The app only requests the minimum set of permissions necessary. | L1 | Tentative | 😅 |
| MSTG-PLATFORM-2 | All inputs from external sources and the user are validated and if necessary sanitized. This includes data received via the UI, IPC mechanisms such as intents, custom URLs, and network sources. | L1 | Infeasible | ❌ |
| MSTG-PLATFORM-3 | The app does not export sensitive functionality via custom URL schemes, unless these mechanisms are properly protected. | L1 | Tentative | 😅 |
| MSTG-PLATFORM-4 | The app does not export sensitive functionality through IPC facilities, unless these mechanisms are properly protected. | L1 | Tentative | 😅 |
| MSTG-PLATFORM-5 | JavaScript is disabled in WebViews unless explicitly required. | L1 | Complete | ✔️ |
| MSTG-PLATFORM-6 | WebViews are configured to allow only the minimum set of protocol handlers required (ideally, only https is supported). Potentially dangerous handlers, such as file, tel and app-id, are disabled. | L1 | Good | 👍 |
| MSTG-PLATFORM-7 | If native methods of the app are exposed to a WebView, verify that the WebView only renders JavaScript contained within the app package. | L1 | Tentative | 😅 |
| MSTG-PLATFORM-8 | Object deserialization, if any, is implemented using safe serialization APIs. | L1 | Soon... | 🕓 |
| MSTG-PLATFORM-9 | The app protects itself against screen overlay attacks. (Android only) | L2 | Good | 👍 |
| MSTG-CODE-1 | The app is signed and provisioned with a valid certificate, of which the private key is properly protected. | L2 | Infeasible | ❌ |
| MSTG-CODE-2 | The app has been built in release mode, with settings appropriate for a release build (e.g. non-debuggable). | L2 | Complete | ✔️ |
| MSTG-CODE-3 | Debugging symbols have been removed from native binaries. | L2 | Complete | ✔️ |
| MSTG-CODE-4 | Debugging code and developer assistance code (e.g. test code, backdoors, hidden settings) have been removed. The app does not log verbose errors or debugging messages. | L2 | Partial | 💔 |
| MSTG-CODE-5 | All third party components used by the mobile app, such as libraries and frameworks, are identified, and checked for known vulnerabilities. | L2 | Infeasible | ❌ |
| MSTG-CODE-6 | The app catches and handles possible exceptions. | L2 | Infeasible | ❌ |
| MSTG-CODE-7 | Error handling logic in security controls denies access by default. | L2 | Infeasible | ❌ |
| MSTG-CODE-8 | In unmanaged code, memory is allocated, freed and used securely. | L2 | Tentative | 😅 |
| MSTG-CODE-9 | Free security features offered by the toolchain, such as byte-code minification, stack protection, PIE support and automatic reference counting, are activated. | L2 | Infeasible | ❌ |