DAST observes a running service from outside. This perspective helps establish whether protection added to a mobile client changes API behavior.
Evaluation approach
The test plan should cover normal application requests and the server's independent verification rules. Seeing the application close is not sufficient evidence.
Application example
Exercise a restricted workflow with an authorized test account. Check that an operation blocked on the client did not create a corresponding record on the backend.
Limits and considerations
DAST does not automatically cover every code path inside an application or every point of interference on the device.
Define what a successful test means
Dynamic security testing examines how a running system responds to inputs. RASP may be active during the test, so distinguish a rejection from application logic from one produced by the protection layer.
Testing a baseline build alongside the protected version under appropriate laboratory conditions can help identify the cause. The package intended for release still needs its own test result. Success with a development build does not establish equivalent behavior under store signing and production configuration.
Checks and decisions
- Record the protection state
- Identify flows outside coverage
- Inspect the API outcome
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.