Mobile App Shielding and RASP Buyer's Guide

Mobile apps run on devices the publisher does not control, so anyone can decompile them, hook them at runtime, repackage them or run them on rooted phones and emulators to commit fraud. App shielding products add obfuscation, anti-tampering, anti-debugging, environment checks and runtime application self-protection (RASP) to the compiled app, and many now pair those client-side controls with server-side attestation. This buyer's guide explains what the category does, when it is worth paying for, the capabilities to require, how to run a fair evaluation and the pitfalls that turn shielding into false confidence. It is vendor-neutral and written for mobile security leads, fraud teams and AppSec buyers.

Key takeaways

Shielding is defence in depth, not a fix. OWASP MASVS-RESILIENCE says the absence of resilience controls is not in itself a vulnerability, and that obfuscation must never replace sound architecture and server-side validation.
Buy for a threat, not a checkbox. Repackaging, credential and payment fraud, cheating, API scraping and model or IP theft each need a different mix of capabilities.
Server-side attestation is the anchor. Client checks can be bypassed; Google Play Integrity and Apple App Attest let your backend verify the app and device before acting on a request.
Test bypass resistance yourself. Ask a red team to defeat each protection during the proof of concept, using the OWASP MASTG resilience tests as the script.
Measure the cost to legitimate users. False positives on custom ROMs, older devices and accessibility tools, plus app size and start-up time, decide whether shielding survives in production.

What the category does

OWASP MASVS groups these controls under MASVS-RESILIENCE, Resilience Against Reverse Engineering and Tampering, with four controls. App shielding products implement them through build-time transformation (a compiler plug-in, Gradle or Xcode build step, or post-build binary processing) plus a runtime library and, increasingly, a backend service.

MASVS control	What it requires	Typical product capabilities
MASVS-RESILIENCE-1	The app validates the integrity of the platform	Root and jailbreak detection, emulator detection, hooking framework detection, integration with Play Integrity device verdicts and App Attest
MASVS-RESILIENCE-2	The app implements anti-tampering mechanisms	Signature and certificate checks, file and resource integrity checks, repackaging detection, runtime code integrity
MASVS-RESILIENCE-3	The app implements anti-static analysis mechanisms	Name obfuscation, string encryption, control flow flattening, instruction substitution, dead code injection, packing, native code protection
MASVS-RESILIENCE-4	The app implements anti-dynamic analysis techniques	Anti-debugging, detection of instrumentation and hooking, debugger and trace detection, continuous rather than one-off checks

RASP in the mobile sense means the app detects these conditions at runtime and reacts: report, degrade, block a transaction or exit. It overlaps with server-side RASP for web applications in name only. See the Interactive Application Security Testing and RASP Guide for the server-side category, and the OWASP Mobile Top 10 M7 Insufficient Binary Protections Guide for the risk that shielding addresses.

Adjacent categories: mobile threat defence (MTD) protects the device and is deployed by the device owner; see the Mobile Threat Defense Buyer's Guide. Fraud and bot platforms analyse behaviour server-side. Many shielding suites now include SDK telemetry that feeds fraud tools, so define the boundary before you buy.

When you need it

High-value client logic: banking, payments, wallets and trading apps where a hooked or repackaged app can authorise transactions or harvest credentials.
Revenue at the client: games, media and subscription apps where tampering unlocks paid features or enables cheating.
Abuse of your APIs: scrapers and bots that pose as your app. Attestation lets the backend tell genuine app traffic from scripts; see the Application Security Guide for the wider API picture.
Intellectual property in the binary: proprietary algorithms or on-device machine learning models. MASVS lists these among the business assets resilience can protect.
Regulatory or scheme expectations: some payment and banking schemes expect resilience controls for apps that handle card data or authentication. Confirm the exact requirement with the scheme or regulator rather than relying on a vendor summary.

When to hold back: MASVS cautions that for government, health and other public-interest apps, obfuscation reduces transparency and independent verification, and device checks can exclude legitimate users. In those cases favour open, verifiable design, strong cryptography and server-side validation, and keep resilience controls light.

Define requirements

Threat model: name the attacks you are paying to raise the cost of (repackaging, hooking to bypass checks, credential harvesting through overlays, emulator farms, API scraping, code theft).
Platforms and toolchains: Android (Kotlin, Java, NDK), iOS (Swift, Objective-C), and cross-platform frameworks (Flutter, React Native, Unity, .NET MAUI). Shielding that does not understand your framework protects only the shell.
Build integration: CI systems, signing flow (Play App Signing, Apple distribution), app bundle formats (AAB), bitcode or symbol handling, and whether protection happens before or after signing.
Reactions: which detections should log only, which should block a transaction, and which should end the session. Most organisations want reactions decided server-side.
Attestation: whether you need Play Integrity and App Attest integration, a vendor attestation service, or both, and who verifies tokens.
Operational limits: acceptable increase in app size and cold-start time, supported OS versions, and tolerance for false positives on legitimate devices.
Data handling: what telemetry the SDK collects, where it is processed, and how it affects store privacy disclosures such as the Play data safety form and Apple privacy labels.

Capability areas

Capability	What good looks like	Why it matters
Code obfuscation	Name, string, control flow and native code obfuscation, configurable per class or function, with stable crash symbolication	Raises the cost of understanding security-relevant code (MASTG-TEST-0368 and 0369 check for insufficient obfuscation)
Anti-tampering	Signature, resource and code integrity checks spread through the app, not one function that can be patched out	Repackaged and backdoored copies on third-party stores
Environment detection	Root, jailbreak, emulator, hooking and debugger detection with tunable sensitivity and clear signals per check	Many client attacks need an instrumented or privileged environment
Runtime reaction (RASP)	Configurable responses, ideally reported to the backend so policy lives server-side	Lets you degrade or block at the right moment instead of crashing the app
Attestation integration	Support for Play Integrity standard requests and App Attest assertions, with backend verification libraries	Server-side trust that does not depend on the client's own logic
Overlay, screen capture and accessibility abuse signals	Detection of screen recording, overlays and accessibility services, with care for legitimate assistive tools	Common in banking trojans; see the Mobile Malware Guide
Secrets and key protection	White-box cryptography or secure storage wrappers, used only where server-side alternatives are impossible	Embedded API keys are extractable regardless of obfuscation
Telemetry and console	Event export to SIEM or fraud tools, per-version dashboards, raw event access	Detection value comes from the data, not the block

Platform attestation baseline

Before paying for client checks, understand what the platforms provide. Google's Play Integrity API returns verdicts on whether the binary is recognised by Google Play (appRecognitionVerdict of PLAY_RECOGNIZED), whether the user is licensed (LICENSED), and device labels such as MEETS_BASIC_INTEGRITY, MEETS_DEVICE_INTEGRITY and MEETS_STRONG_INTEGRITY. Google recommends standard requests for most use cases, tiered rather than binary enforcement, running in telemetry mode first, and not using the API as the sole anti-abuse mechanism; the default quota is 10,000 requests per day per app. Apple's App Attest (DCAppAttestService) creates a Secure Enclave key, attests it through Apple's servers, and signs later requests with assertions; Apple says not all devices support it, so apps must check isSupported and the server must handle unsupported devices. Ask every vendor how their product adds to these, rather than replacing them.

Evaluation criteria and questions to ask

Criterion	Weight guide	Evidence to request
Bypass resistance	High	Your own red team results against MASTG resilience tests, not vendor claims
False positive rate	High	Pilot data from your install base, by device model and OS version
Framework coverage	High if cross-platform	Demonstration on your actual Flutter, React Native or Unity build
Performance impact	Medium to high	Measured app size and cold-start delta on low-end devices
Build and release fit	Medium	Working CI pipeline integration with your signing flow
Server-side integration	Medium to high	Backend verification library, token format documentation, outage behaviour
Privacy and data handling	Medium	Data inventory of SDK telemetry, retention, processing locations

Questions to ask vendors

Which MASVS-RESILIENCE controls does each feature address, and which MASTG tests do you expect a protected build to pass?
How are checks distributed through the code so that removing one function does not disable protection?
How quickly do detections update after a new root-hiding or hooking technique appears, and does an update need a new app release?
Can reactions be decided server-side, and can we run every detection in report-only mode first?
How do you integrate with Play Integrity and App Attest, and what happens to our app and backend when those services are unavailable?
What is the measured impact on app size, start-up time and battery for a build like ours?
How does obfuscation interact with crash reporting, symbol upload and store review?
What data does the SDK collect, where is it sent, and what must we declare in store privacy disclosures?
How do you secure your own build tooling and SDK distribution, given that your plug-in runs inside our build? See the Software Supply Chain Security Guide.
What is the licensing model (per app, per install, per active user), and what happens to protected builds if the contract ends?

Deployment and integration

Start with telemetry: ship detections in report-only mode to a percentage of users and measure verdict distribution by device and OS, as Google advises for Play Integrity.
Move decisions to the backend: attach attestation tokens and shielding signals to sensitive requests (login, payee add, payment, reward claim) and enforce tiered responses there: allow, allow with limits, step-up, deny.
Protect selectively: apply heavy obfuscation to security-relevant and IP-bearing code, lighter protection elsewhere, to control size and performance.
Integrate into CI: protection runs on every release build with deterministic configuration under version control. Keep unprotected builds for internal testing only.
Plan rollback: keep the ability to turn reactions off remotely and to ship an unprotected or lightly protected build quickly if a false positive spike hits a device family.
Feed detection: send events to the SOC or fraud platform and review them alongside account takeover signals. See the Account Takeover Prevention Guide.

Red flags

Claims that the app becomes "unhackable" or that shielding removes the need for server-side checks.
No way to run detections in report-only mode or to tune them per device family.
Refusal to allow your testers to attempt bypasses during the evaluation.
Protection that cannot handle your cross-platform framework's code, leaving the business logic unprotected.
Opaque SDK telemetry, or data sent to locations you cannot document in privacy disclosures.
Advice to embed long-lived API keys or secrets in the app because "the obfuscation protects them".
Pricing tied to active users with no cap, making growth expensive.

Pitfalls

Client-only decisions: the app decides it is safe and tells the server so. A hooked app simply reports "safe". Decisions belong where the attacker cannot edit them.
Excluding real users: blocking on any root signal locks out users of custom ROMs and unusual devices, and some accessibility tools trip overlay checks. MASVS flags this platform lock-in risk.
Breaking crash analytics: obfuscation without symbol mapping leaves engineering blind to real defects.
Single point checks: one root check at start-up, patched out in minutes. MASTG-BEST-0047 recommends continuous anti-debugging checks rather than a single check.
Shelfware: the SDK ships, telemetry is never reviewed, and nobody notices when a bypass appears.

Proof of concept

Protect one production-like build of your main app, including any cross-platform layer, through your real CI and signing flow.
Measure app size, cold-start time and crash rate against the unprotected build on low-end and current devices.
Have an internal or contracted tester run the MASTG resilience tests (root, jailbreak, emulator, anti-debugging, hook detection, file integrity, obfuscation) and attempt to bypass each protection within a fixed time box.
Run detections in report-only mode on a beta cohort for at least two weeks and review false positives by device and OS.
Wire attestation into one sensitive backend endpoint and test behaviour when the attestation service is unavailable.
Export events to your SIEM or fraud platform and confirm they are usable for investigations.
Score results against the evaluation table and record bypass time per protection.

Buyer checklist

Threat model and protected assets written down before vendor contact.
Platform attestation (Play Integrity, App Attest) understood and planned independently of any vendor.
Framework coverage proven on your own build.
Bypass testing done by your own testers.
False positive, size and start-up data from your install base.
Reactions enforced server-side with tiered responses and remote rollback.
SDK data inventory approved for privacy disclosures.
Telemetry routed to a team that will review it.

Standards and references

How NHI Mgmt Group can help

We provide independent requirements, RFP and evaluation support across application, mobile and identity security. Browse vendors in our products directory or contact us.

Mobile App Shielding and RASP Buyers Guide: Questions to Ask Vendors