The updates in the OWASP Mobile Application Standard (MAS) for 2025 will incorporate a new MASWE called "RASP Techniques Not Implemented." Let us preview the contributed draft written by Talsec
Last updated
Was this helpful?
RASP (Runtime Application Self-Protection) encompasses techniques such as root or jailbreak detection, unauthorised code or code execution, malware detection, system state, data logging and data flow. It provides a systematic, organised management approach to securing mobile applications in real time from potential threats.
Ensure that the application flow remains secure and untampered at all times.
Enable applications to detect and trigger responses to threats, such as:
Warning the user.
Killing the app.
Locking access to certain features.
Without RASP implementation, applications remain vulnerable to attacks during runtime. RASP techniques assure that the app continuously monitors both its own state and the device environment to detect threats like malware, root, or integrity issues.
Independent decoupled protection updates.
Remote configuration of security rules.
Threat intelligence gathering.
Fast security incident remediation.
Providing data for security analysis.
Speed and timing of checks is also important and crucial for response times and ensuring no gaps in detection rounds, with control timing checking sensitive steps in the app. Incorporating RASP into an app ensures continuous protection from threats, ultimately minimising risk and improving overall security.
Mobile app security and user security can be disrupted in various scenarios, including:
The application does not comprehensively process information and fails to account for system weaknesses or its own vulnerabilities, potentially leading to breached environment integrity.
Direct reactions to detected threads are not properly executed or integrated into the application’s business logic.
Security rules cannot be effectively defined based on discovered weaknesses, as this approach lacks the broader perspective needed to address all potential threats and ensure comprehensive protection.
Loss of Control and Monitoring: One of the key advantages of RASP is the ability to continuously control and monitor the mobile app’s state and the device environment in real-time. Without these features, the application may fail to detect or respond to unauthorised modifications, malware presence, or tampering attempts.
Missed Threat Intelligence: Without continuous monitoring, security checks, and data logging, we lose a critical overview of potential threats, making it harder to identify emerging attack patterns and respond to malicious activities effectively.
Loss of Manageability and Updateability of Detection Techniques: Without RASP, applications lose the ability to update security rulesets, reset policies/settings, and adjust risk scoring in older or already released apps.
To enhance the security of your mobile application, implement detection mechanisms that continuously monitor the app's state and device environment.
Implement response actions for detected threats to mitigate potential risks, such as:
Killing the app,
Warning the user,
Logging information about potential risks to the database.
RASP (Runtime Application Self-Protection) is designed to monitor and protect the application during runtime by detecting and responding to threats in real-time. The test verifies if the application can identify and react to malicious modifications, such as code tampering, root or jailbreak environment, and attempts to bypass security mechanisms. It also checks if the application has the ability to protect sensitive data and prevent unauthorised access to critical operations or features.
By conducting this test, we ensure that the app is capable of defending against runtime attacks and maintaining its integrity even in compromised environments. If RASP techniques are not implemented or are improperly configured, the app may be vulnerable to various security threats, including data breaches, unauthorised access, and malicious modifications.
Ensure that all security checks and protection mechanisms expected from RASP are present and enabled with the application. To test the RASP policy that the app enforces, a written copy of the policy must be provided. The policy should define available checks and their enforcement. For example:
Root detection.
Screen lock enforcement.
Code integrity checks.
Detection of dynamic analysis.
Based on the previous step, attempt to simulate threats to test if the application reacts as expected. This can involve various scenarios such as:
Launching the mobile application on a rooted device.
Launching the mobile application on a device without a screen lock enabled.
Attempting to repackage the application and launching it.
Launching the application in an emulator.
Verify that the application properly detects and responds to potential threats. There are various scenarios in which a mobile application can respond to these threats, such as:
Killing the app.
Warning the user about the detected threat.
Logging information about potential risks to a database or SIEM.
The output depends on the specific reactions set up for the mobile application. The results should demonstrate the app’s behaviour when a threat is detected or triggered, for example:
Application is terminated.
Application displays a warning message.
Application sends information to a database or SIEM. Testers should ensure that the collected threat intelligence data are rich enough.
The test case fails if the mobile application does not react as expected to the detected threats.
written by Martin Žigrai, Tomáš Soukal
Use third-party solutions, which specialise in threat detection and real-time security monitoring (e.g. ).
