All insights

31 August 2026

Mobile Application Security & RASP: OWASP and SAMA Guide

Mobile application security in the modern threat landscape, covering RASP, application shielding, OWASP MASVS resilience controls, SAMA requirements, and the role of Mobile Application Penetration Testing.

Mobile Application Security and RASP – OWASP MASVS and SAMA-AXPERT

Mobile Application Security and RASP: OWASP MASVS and SAMA Requirements

Mobile applications have become a critical channel for banking, payments, fintech, e-commerce and digital services. As organizations increasingly depend on mobile applications to deliver sensitive services, attackers are also targeting the application, the mobile device and the communication between the application and backend systems.

Traditional Mobile Application Penetration Testing remains essential for identifying vulnerabilities, but modern mobile applications also require protection against attacks that occur while the application is running. Rooted devices, jailbroken devices, emulators, Frida, Xposed, application tampering, repackaging, overlays and screen-mirroring attacks can expose applications even when the underlying code has been securely developed.

This has increased the importance of Runtime Application Self-Protection (RASP) and application shielding.

For financial institutions, these controls can also support regulatory requirements. The OWASP Mobile Application Security Verification Standard (MASVS) provides a structured framework for mobile application security, while requirements issued by the Saudi Central Bank (SAMA) include specific expectations around application shielding, anti-tampering and compromised-device detection.

The Current Mobile Application Security Landscape

Mobile application security is no longer limited to identifying coding vulnerabilities before an application is released.

A modern mobile application may be attacked at several different layers:

Attackers may attempt to reverse engineer an application, extract sensitive logic, modify application code, run the application on a rooted or jailbroken device, attach dynamic instrumentation tools or manipulate transactions.

  • Application source code and compiled binaries
  • Mobile device operating system
  • Application runtime environment
  • APIs and backend services
  • Authentication mechanisms
  • Local data and cryptographic keys
  • User interface and screen
  • Application distribution and installation process
  • User and transaction behaviour

Common attack techniques include:

  • Root and jailbreak attacks
  • Emulator and virtual-device attacks
  • Frida and Xposed-based instrumentation
  • Debugging and runtime hooking
  • Code injection
  • Application tampering and repackaging
  • Screen overlay and tapjacking
  • Accessibility-service abuse
  • Screen capture and screen mirroring
  • Remote-access attacks
  • Cryptographic-key extraction
  • API manipulation
  • Authentication and authorization attacks
  • Business-logic exploitation

Consequently, organizations need a layered mobile application security strategy that combines secure development, penetration testing, application shielding, runtime protection, API security and fraud detection.

What Is RASP?

Runtime Application Self-Protection (RASP) is a security technology that enables an application to detect and respond to threats while it is running.

Unlike traditional perimeter security technologies, RASP operates within the application runtime environment. Depending on the solution, it can identify indicators of application tampering, device compromise, debugging, hooking, instrumentation and other runtime attacks.

A RASP solution may detect:

  • Rooted Android devices
  • Jailbroken iOS devices
  • Emulators and virtual environments
  • Debuggers
  • Frida and other instrumentation frameworks
  • Xposed/LSPosed
  • Runtime hooking
  • Code injection
  • Application tampering
  • Repackaged applications
  • Malicious overlays
  • Certain screen-capture and screen-mirroring scenarios

Depending on the policy configured by the organization, the application may respond by generating an alert, terminating execution, blocking a transaction or restricting access to sensitive functionality.

However, RASP is not a replacement for Mobile Application Penetration Testing.

RASP protects the application against certain attacks during runtime, while penetration testing identifies weaknesses in the application, APIs, authentication mechanisms, business logic and architecture.

The two controls therefore complement each other.

RASP and OWASP MASVS

The OWASP Mobile Application Security Verification Standard (MASVS) provides a framework for defining and verifying mobile application security controls.

For RASP and application shielding, the most relevant section is MASVS-RESILIENCE. OWASP divides resilience into platform integrity, anti-tampering, resistance to static analysis and resistance to dynamic analysis.

OWASP MASVS and RASP Mapping

OWASP MASVS RASP MAPPING -AXPERTCYBER
OWASP MASVS RASP MAPPING

OWASP treats resilience as defense in depth. Applications still need appropriate controls for storage, cryptography, authentication, networking, platform interaction, code quality and privacy.

Therefore, an organization should not interpret RASP as a substitute for a complete OWASP MASVS assessment.

SAMA and Mobile Application Security

The regulatory case for application shielding becomes particularly important for Saudi financial institutions.

The SAMA Cyber Resilience Fundamental Requirements (CRFR) specifically addresses application shielding. Section 3.2.8 states that entities should implement shielding techniques in application design, including code obfuscation, white-box cryptography and anti-tampering.

This creates a direct connection between SAMA requirements and technologies used for application shielding and RASP.

SAMA and Mobile Application Protection Mapping

SAMA MAPPING MOBILE APPLICATION SECURITY -AXPERTCYBER
SAMA MAPPING OF MOBILE APPLICATION SECURITY

SAMA’s Counter-Fraud requirements are particularly relevant because they require mobile applications to detect devices that have been subjected to rooting or jailbreaking and subsequently block the application or restrict access to sensitive data or functionality.

This provides a strong regulatory justification for implementing compromised-device detection and appropriate application controls.

RASP Does Not Replace Mobile Application Penetration Testing

One of the most important distinctions in mobile application security is the difference between protection and assessment.

RASP is primarily a protective control.

Mobile Application Penetration Testing is an assessment activity.

A penetration test may identify:

  • Broken authentication
  • Broken authorization
  • Insecure APIs
  • IDOR vulnerabilities
  • Business-logic flaws
  • Insecure cryptographic implementation
  • Sensitive data exposure
  • Insecure local storage
  • Certificate-validation weaknesses
  • Improper platform interaction
  • Vulnerable third-party components

These vulnerabilities cannot simply be solved by installing a RASP solution.

SAMA’s CRFR also requires comprehensive vulnerability assessment and penetration testing, including application and infrastructure layers. Penetration testing is required at least twice annually and following major or critical changes.

The appropriate approach is therefore:

Mobile VAPT → identify weaknesses

RASP → protect against applicable runtime attacks

RASP Bypass Testing → validate protection

Continuous Monitoring → detect attacks

The Ideal Mobile Application Security Architecture

A mature mobile application security program should combine several complementary layers.

Security should begin during development through:

  • Secure SDLC
  • Secure coding
  • Threat modelling
  • SAST
  • Software Composition Analysis
  • Secrets detection
  • Code review
  • Secure architecture

The application should be assessed using OWASP MASVS and MASTG.

Testing should cover both static and dynamic security controls and should include attempts to bypass application protection mechanisms.

  • Mobile Application VAPT

RASP provides runtime protection against threats such as:

Root/Jailbreak → Emulator → Frida/Xposed → Debugging → Hooking → Injection → Tampering → Repackaging

Depending on the selected platform, additional controls may include overlay detection, accessibility abuse detection, screen protection and remote-access risk detection.

  • RASP and Application Shielding

High-value mobile applications may require:

  • Code and Data Protection
  • Advanced code obfuscation
  • Control-flow protection
  • Code/resource encryption
  • White-box cryptography
  • Secure key storage
  • Hardware-backed cryptography

Mobile application security cannot stop at the application itself.

Backend APIs should independently enforce:

A RASP solution cannot compensate for a server-side authorization vulnerability.

  • API and Backend Security
  • Authentication
  • Authorization
  • Input validation
  • Rate limiting
  • Transaction controls
  • Business-logic security
  • API abuse detection

Banking and payment applications may also require:

This is particularly relevant when implementing SAMA’s Counter-Fraud requirements.

  • Device and Fraud Intelligence
  • Device fingerprinting
  • Device reputation
  • Remote-access detection
  • Malware indicators
  • Behavioral analytics
  • Transaction-risk analysis
  • Trusted-device management
  • Step-up authentication

Security events generated by RASP and application-shielding solutions can contribute to centralized security monitoring.

Organizations should also periodically test whether their protection mechanisms can be bypassed.

This makes Mobile VAPT + RASP + continuous validation significantly more effective than relying on any single control.

  • Security Monitoring and Continuous Validation

Building a Complete Mobile Application Security Program

The modern mobile application security model can therefore be represented as:

Secure SDLC

OWASP MASVS-Based Mobile VAPT

RASP / Application Shielding

Code & Data Protection

API & Backend Security

Device & Fraud Intelligence

SIEM / Security Monitoring

Continuous Security Testing

This layered approach provides both vulnerability discovery and runtime resilience.

For financial institutions, it also creates a stronger regulatory security architecture by connecting technical controls to frameworks such as OWASP MASVS and SAMA cybersecurity and counter-fraud requirements.

Mobile Application Security Services from Axpert Cyber

Mobile applications handling financial transactions, customer information and sensitive credentials require more than periodic security testing.

Axpert Cyber provides end-to-end Mobile Application Security services to help organizations identify vulnerabilities, strengthen runtime protection and validate their security controls.

Our services include:

  • Mobile Application Penetration Testing
  • OWASP MASVS and MASTG-based Security Assessment
  • RASP and Application Shielding Solutions
  • Root and Jailbreak Detection
  • Emulator and Compromised-Device Detection
  • Anti-Tampering and Anti-Repackaging
  • Anti-Debugging and Anti-Hooking
  • Frida/Xposed Detection
  • Code Obfuscation and Anti-Reverse Engineering
  • API Security Assessment
  • Mobile Fraud and Device-Risk Protection
  • RASP Bypass and Control-Effectiveness Testing
  • SAMA Regulatory Control Mapping

Whether your organization needs to assess an existing mobile application, strengthen its runtime protection, or implement application-shielding controls aligned with regulatory requirements, Axpert Cyber can help design and validate a mobile application security architecture based on your risk profile.

Secure your mobile application before attackers find the weakness — and protect it after deployment.

Talk to Axpert Cyber

Contact Axpert Cyber to discuss Mobile Application Penetration Testing, RASP and Application Shielding solutions for your organization.

Share this insight

Next step

Need help applying this to your environment?

Our team helps organisations operationalise frameworks like ISO 27001, PCI DSS, NESA, SAMA CSF, and PDPL. Tell us what you are trying to achieve.