All guides
Browse by topic, or search for a specific concept, tool or platform.
Runtime protection: where RASP fits in an application
Application protection goes beyond obscuring compiled code. RASP evaluates signs of interference while a distributed application runs, providing the runtime layer of…
Read the guideFrom protection signal to transaction decision: the RASP flow
A security check and a security decision serve different purposes.
Read the guideApp shielding and RASP: understanding product scope
App shielding usually describes products that combine code hardening with runtime checks. RASP focuses on security decisions made while the application is running.
Read the guideThe difference between in-app protection and antivirus
Antivirus aims to identify malicious software on a device. Application protection focuses on the security of its own code, data and operations.
Read the guideWhat do mobile app protection and a WAF cover together?
A WAF evaluates web traffic reaching the server; in-app protection evaluates client execution. The two systems collect information at different observation points.
Read the guideHow SAST findings inform an application protection plan
SAST examines source code and data flows for issues that developers can fix during development. Runtime defenses operate at a different control point.
Read the guideCombining DAST with mobile protection testing
DAST observes a running service from outside. This perspective helps establish whether protection added to a mobile client changes API behavior.
Read the guideMobile Threat Defense and application protection
MTD broadens visibility into devices, networks and mobile threats. App protection applies controls directly to a particular application's code and operations.
Read the guideAn application protection threat model for Android and iOS
Prepare the threat model before assembling a product list. Identify the asset, the operation in which it needs protection and the capabilities of the attacker it must…
Read the guideDrawing trust boundaries in a mobile application
The device is under the user's control. Values produced by the application cannot all carry the same authority as trusted server data.
Read the guideShould the device or server make a protection decision?
Local decisions provide a quick response. Server decisions combine account details, history and transaction context.
Read the guideWhy root and jailbreak need distinct policies
Root concerns Android privileges; jailbreak concerns modifications to restrictions on Apple's platform.
Read the guideThe practical contribution of code obfuscation
Code obfuscation changes names, control flow or data representation to increase analysis cost. It does not make it safe to place server secrets in a client.
Read the guideAnti-tamper: detecting and stopping package modification
Anti-tamper checks look for departures from an application's expected integrity. Producing an alert and protecting a critical function require separate verification.
Read the guideHow to assess anti-debugging controls
Debugging is a normal part of development. Observing sensitive execution in a production application creates a different risk.
Read the guideAnti-hooking and the protection of critical functions
Hooking allows a function's behavior to be observed or changed at runtime. Anti-hooking controls aim to limit the effect of that interference on an application.
Read the guideApp attestation: establishing application identity
Attestation evaluates claims made by a client against an independent source of trust. Android and iOS do not use the same evidence format.
Read the guideHow false positives affect application protection
A false positive classifies legitimate use as risky. Its impact extends beyond support-ticket volume: it can interrupt payments, access and account recovery.
Read the guideAccess during failures: fail-open and fail-closed
A verification service that does not respond has not proved the application untrustworthy. A failure policy defines which operations can continue under uncertainty.
Read the guideMeasuring the performance cost of application protection
APK or IPA size alone does not measure protection overhead. Startup time, transaction latency, memory, battery use and error rates all affect the user experience.
Read the guideSDK, compiler and post-build protection options
Where protection enters the delivery pipeline affects maintenance cost. SDKs, compiler plugins and post-build processing create different integration requirements.
Read the guideWhat questions should protection telemetry answer?
Useful telemetry goes beyond recording that something happened. It connects the control, the policy and the resulting transaction outcome.
Read the guideWhich vulnerabilities does application protection leave open?
A hardened client does not make faulty authorization or account recovery safe. Understanding protection limits helps direct investment where it matters.
Read the guideDefining success in an app protection proof of concept
A proof of concept tests security and operational expectations in your own application, rather than simply demonstrating a product.
Read the guideA learning path for Android app protection and iOS app protection
Understanding a platform's trust model comes before memorizing tool names. Code, data, identity and server decisions are interconnected.
Read the guidePlay Integrity API in Android app protection
The value of Play Integrity comes from binding evidence to the correct Android application and operation, rather than merely obtaining a token.
Read the guidePlay Integrity standard requests
In the standard request flow, assess preparation overhead separately from verification for each operation.
Read the guidePlay Integrity classic requests and nonces
Nonce handling in a classic Play Integrity request is a protocol responsibility. Specify who generates the value, which operation it belongs to and when it is consumed.
Read the guideInterpreting Play Integrity verdicts
Integrity-response fields answer different questions. Collapsing application recognition, device conditions and unevaluated states into one safe label can produce…
Read the guideProtecting key use with Android Keystore
The conditions under which a key can be used matter alongside its storage location. Android Keystore provides platform mechanisms for establishing that boundary.
Read the guideWhat Android StrongBox provides
StrongBox availability can affect device coverage. Assess a requirement for a stronger key boundary alongside legitimate users' ability to access the service.
Read the guideAndroid key attestation
A key-attestation record becomes meaningful only after the expected challenge and trust chain are verified.
Read the guideAndroid app signing and RASP
An Android signature establishes a release identity. A protection system must match its expected certificate to the package that the store or another distribution…
Read the guideAPK, AAB and the final protected package
The AAB file alone is not the complete input to a security assessment.
Read the guideAndroid R8 and runtime protection
R8 build transformations and runtime defenses serve different purposes.
Read the guideAndroid Network Security Configuration
Network security configuration makes an application's connection-trust rules explicit. Establish whether every network client and SDK actually follows those rules.
Read the guideDesigning certificate pinning on Android
Android pinning is an availability decision as well as a trust decision.
Read the guideApproaching Android root detection
A root signal provides information about platform risk, not user intent. Android app protection policy should combine it with transaction impact and other evidence.
Read the guideAndroid emulator detection and legitimate use
Emulator detection can be one part of an anti-automation strategy. Distinguish development, testing and legitimate usage from abusive scenarios.
Read the guideAndroid overlay and tapjacking defenses
Overlay risk concerns the relationship between what a user sees and the operation they approve.
Read the guideBalancing Android accessibility and security
Accessibility services are essential for many people to use an application. Security policy should not remove that legitimate access through a blanket blocking rule.
Read the guideAndroid screen capture protection
Sensitive data can leak through visual copies of a screen as well as through files. Determine screen-protection requirements by the data class displayed in each view.
Read the guideAndroid WebView security and RASP
WebView introduces a separate content and execution boundary inside an application.
Read the guideAndroid App Links and deep-link security
A verified App Links relationship does not make every incoming parameter trustworthy.
Read the guideAndroid exported components
Exported Android components create additional entry points. Separate tests are needed to establish that controls on the main screen also protect these paths.
Read the guideAndroid PendingIntent security
A PendingIntent can let another party initiate limited work on your application's behalf.
Read the guideRisks of dynamic code loading on Android
Code loaded later can change the security scope of a reviewed release package. Source verification, privilege boundaries and store requirements belong in that design.
Read the guideAndroid native libraries and JNI
JNI and native libraries introduce their own memory-safety and input-validation responsibilities.
Read the guideAndroid backup and sensitive data
Backups create additional copies of sensitive data and allow it to reappear on another device.
Read the guideAndroid Verified Boot and application trust
A healthy boot chain strengthens the application's platform foundation. Application logic, API authorization and user transactions still require separate controls.
Read the guide