Application protection goes beyond obscuring compiled code. RASP evaluates signs of interference while a distributed application runs, providing the runtime layer of an Android app protection or iOS app protection architecture.
Evaluation approach
Code integrity, process behavior and environmental information produce signals with different levels of assurance. When combining them under one policy, define which operations each signal may affect.
Application example
In a payment application, a suspicious environment might still permit balance viewing while requiring additional verification for a transfer to a new recipient. This distinction connects protection to business risk.
Limits and considerations
Local protection does not remove a vulnerability. The server must independently check account ownership and transaction authorization.
Reading a protection chain
RASP stands for Runtime Application Self-Protection. In a mobile application, protection focuses on checking the application's own trust assumptions rather than managing the entire device. A risk detected on someone's phone and an unauthorized transaction on that person's account are therefore different events.
An integrity check performed only at startup does not provide the same assurance as fresh evidence bound to a transfer request. During design review, ask where the signal originates, how it is protected in transit and which component enforces the decision. If the server at the end of the chain accepts the client's decision without verification, a strong local check alone will not close the gap.
Checks and decisions
- Identify protected operations
- Separate detection from enforcement
- Compare results with normal devices
Sources
The primary references above provide the technical basis. Example workflows and evaluation suggestions are this publication’s explanations, not independent test results for a particular product.