All guides · Page 6
Browse by topic, or search for a specific concept, tool or platform.
Defining application protection scope with OWASP MASVS
MASVS provides a shared requirements framework that extends beyond reverse-engineering resistance.
Read the guideOWASP MASTG: planning mobile security tests
MASTG helps turn security requirements into concrete test questions. Defined packages, device conditions and expected outcomes make reports reproducible.
Read the guideOWASP MASWE: a common language for mobile weaknesses
MASWE provides consistent terminology for mobile weaknesses. Classification still needs the application's actual impact and remediation context.
Read the guideTurning a mobile security checklist into evidence
A checked box does not show that a control works. Connect every item to a design decision, executed test and examined artifact.
Read the guideMASVS-RESILIENCE-1: platform integrity and device signals
Platform-integrity assessment explains which environment signals the application trusts. Review scope, unsupported conditions and false-positive effects together.
Read the guideMASVS-RESILIENCE-2: evidence of application integrity
Writing an integrity requirement and assessing tampering in a final package are separate tasks.
Read the guideMASVS-RESILIENCE-3: measuring resistance to static analysis
Success does not mean making all code invisible. Set realistic objectives around specific assets and the effort required to understand them.
Read the guideMASVS-RESILIENCE-4: resistance to dynamic analysis
Dynamic analysis examines interference with a running application. Blocking one research tool does not establish that the entire business risk is controlled.
Read the guideUsing the OWASP Mobile Top 10
The Mobile Top 10 is a starting point for discussing common risks, not an exhaustive acceptance standard for every application.
Read the guideOWASP ASVS and the mobile back end
A mobile application's back end has its own requirements. ASVS helps assess that layer; client protection does not remove server controls.
Read the guideAPI Security Top 10 and application protection signals
APIs can expose abuse paths independently of the mobile package. Assess object, function and resource-consumption controls alongside client evidence.
Read the guideBuilding scenarios with MITRE ATT&CK Mobile
ATT&CK Mobile helps describe threat behavior. Mapping a technique name to a product feature does not prove effectiveness in an application.
Read the guideClassifying mobile security findings with CWE
CWE provides a shared weakness vocabulary. Classification does not replace an explanation of reachable code and business impact.
Read the guideApplying CVSS v4.0 to mobile findings
CVSS helps describe technical severity consistently. Product priority also depends on data value, reachability and business impact.
Read the guideNIST SSDF: placing RASP in secure development
SSDF addresses security across the development lifecycle. A protection product can contribute a control but does not assume responsibility for source, supply chain or…
Read the guideNIST CSF and application protection governance
CSF connects technical controls with organizational risk management. Evaluate mobile protection through ownership, measurement and improvement plans.
Read the guideSLSA and mobile build provenance
SLSA supports discussion of build and supply-chain trust. Keep source provenance connected to the final protected mobile artifact.
Read the guideSPDX for mobile component and license inventories
SPDX supports sharing component and license information. Matching inventories to final packages makes dependency decisions traceable.
Read the guideVEX: explaining whether a vulnerability affects a product
VEX communicates whether a particular vulnerability affects a particular product. An unaffected statement needs technical reasoning and evidence.
Read the guideMobile application security in a PCI DSS context
A protection SDK is only one part of a payment-data architecture. Assess data flows, scope and operational controls against applicable requirements.
Read the guidePCI MPoC and accepting payments on phones
Phone-based payment acceptance includes monitoring and solution components beyond application code. MPoC assessment cannot be reduced to one RASP feature.
Read the guideDesigning RASP telemetry with KVKK in mind
Mobile security events may contain personal data. Technical design should clarify necessity, access and retention, with legal assessment handled separately.
Read the guideMobile security data in a GDPR context
Telemetry linked to a person or device can raise data-protection questions. Assess fields, purpose, transfers and retention against actual application behavior.
Read the guideISO/IEC 27001 and managing mobile security controls
Control ownership, implementation and evidence matter in an ISO/IEC 27001 context. Buying a protection product does not complete a management system.
Read the guideWhat a SOC 2 report says about a RASP supplier
A SOC 2 report provides information about a defined system and period. Its existence does not mean your mobile application passed an independent security test.
Read the guideApplication protection in mobile banking
Viewing balances, adding recipients and transferring funds carry different loss scenarios.
Read the guideRASP for SoftPOS and mobile payment acceptance
When a phone accepts payments, protection decisions affect sales continuity.
Read the guideApplication protection and key security in crypto wallets
Key generation, storage, backup and transaction approval matter alongside application integrity.
Read the guideRASP, cheating and economy security in mobile games
Client resilience and game-economy rules belong together. Rewards and competitive outcomes must not rely solely on modifiable device values.
Read the guideRASP for e-commerce accounts, coupons and payments
Accounts, promotions and payment flows have different abuse risks. Application protection should complement correct server-side business rules.
Read the guideApplication protection and continuity in healthcare apps
Healthcare applications must manage sensitive data and access continuity together.
Read the guideRASP, MDM and privacy in BYOD applications
An enterprise application on a personal phone lacks the same authority as a fully managed device.
Read the guideApplication protection for public-service apps
Public services need security and broad access. Include older devices, accessibility and account recovery in protection acceptance.
Read the guideRASP and DRM in video and media applications
DRM manages content rights while application protection addresses selected client risks. Keep their scopes distinct.
Read the guideProtecting insurance documents and claims
Documents, claims and payment details need different validation. Secure file transport does not prove a claim is genuine or a user is authorized.
Read the guideRASP and delivery records in logistics apps
Delivery applications combine offline records, location and uploads. Device signals should not be treated as proof that a business record is correct.
Read the guideLocation, driver and transaction security in transport apps
Transport applications combine location, driver accounts and payments. Make decisions from transaction context rather than one device label.
Read the guideBooking and account security in travel apps
Booking and account changes can have lasting financial consequences. Client integrity needs server controls for ownership and repeated operations.
Read the guideThe limits of RASP in education and exam apps
Device controls can affect learning and accessibility. Local protection must not be presented as preventing every form of copying or outside assistance.
Read the guideProtecting line and account changes in telecom apps
Line and account changes are more consequential than routine profile edits. Combine device context with authentication and transaction approval.
Read the guideApplication protection for IoT control apps
IoT applications can affect physical devices. Verify relationships between mobile accounts, device registrations and command authority.
Read the guideShared RASP policies in super apps
Different business modules may share one session. Policies should reflect each module's data and transaction risks rather than imposing one global response.
Read the guideRASP integration for fintech SDK developers
A fintech SDK runs inside another organization's application. Define protection coverage, data responsibilities and failures through an explicit integration contract.
Read the guideRASP policies for offline field applications
Offline field work operates with limited assurance. Later validation, conflict resolution and authorization lifetime are core design concerns.
Read the guideWhere small teams should start with application protection
Small teams should establish high-impact fundamentals first. Advanced runtime products cannot balance missing key storage, API authorization or secure delivery.
Read the guideBuild or buy RASP controls?
Building and buying distribute maintenance responsibility differently. Platform changes, test capacity and response work make the decision broader than licensing.
Read the guideComparing application protection, Play Integrity and App Attest
Runtime protection and platform attestation provide different trust sources.
Read the guideAn impartial guide to comparing application protection products
Compare products using the same package and tests. Marketing features are a starting point; security effects, user experience and operational work require observation.
Read the guideRASP for enterprise approval applications
Approval requires knowing what was authorized as well as who approved it. Verify documents, amounts and privilege changes in their transaction context.
Read the guideProtecting loyalty points and campaigns
Loyalty points and promotions are valuable business assets. A healthy device signal does not create unlimited reward entitlement.
Read the guide