Mostly the backend. DAST attacks a running service over HTTP, so it can test the web and API endpoints a mobile app calls. It does not inspect the app binary, local storage, or on-device behavior, so pair it with mobile-specific testing.
What DAST sees in a mobile setting
OWASP's DevSecOps guidance describes DAST as black-box testing that finds weaknesses in a running application by injecting malicious payloads, without needing source code. For a mobile app, "running application" means the server side. The scanner talks to your API the way the app does, and tries to break it.
What it can cover
- Authentication and session handling on the API.
- Input handling on every endpoint: injection, bad types, oversized values.
- Missing or weak access checks, when you test with more than one account.
- Transport settings, such as TLS configuration and headers on web views.
- Error messages that reveal internals.
What it cannot cover
| Area | Why DAST misses it |
|---|---|
| Data stored on the device | Never crosses the network |
| Hardcoded keys inside the app package | Lives in the binary |
| Reverse engineering and tampering | Needs binary analysis |
| Insecure local file or keychain use | On-device behavior |
| Third-party SDK behavior inside the app | Unless it calls your API |
| Certificate pinning bypass risk | Needs device testing |
How to get traffic to scan
- Capture the app's calls. Run the app in a test device or emulator behind a proxy and use it normally.
- Export or build an API definition from the captured traffic, or use the one your backend team keeps.
- Import it into the scanner so each endpoint is tested.
- Add valid tokens. Use a dedicated test account on a test backend.
- Handle pinning. If the app pins certificates, use a debug build for testing, never the release build.
- Run active checks against the test backend only, with disposable data.
Remember the whole picture
A mobile app is a client, a backend and a set of libraries. A complete review covers each.
| Part | Typical check |
|---|---|
| Backend API | DAST or API testing on a test environment |
| App code and binary | Static review and mobile-specific testing |
| Libraries and SDKs | Software composition analysis |
| Network behavior | Proxy-based observation of what is sent |
Checks worth doing by hand
Look at what the app sends on first launch, how it stores tokens, and what happens when the server returns an unexpected response. These are simple to try with a proxy and often reveal more than an automated scan.
A worked example
A team builds a delivery app for phones. The app calls an API for login, orders and payments. They plan their testing as follows.
- Capture traffic. A tester uses a debug build on an emulator behind a proxy, places an order, edits the profile, and logs out. The proxy records 38 distinct API calls.
- Export an API definition from the capture and compare it with the backend team's own definition. Four endpoints in the capture are missing from the official list, including one for an old app version.
- Run a scan on the test backend with a dedicated account. The scan finds weak input validation on the order notes field and a verbose error message that includes a library name.
- Test access by hand. Using order IDs from two accounts, the tester finds that one account can read the other's order. No scanner flagged it.
- Review the app separately. A static review of the app package finds an analytics key stored in the binary, which is outside what a network scan can see.
- Check dependencies. A scan of the app's libraries lists packages with known issues, which goes to a different owner.
The counts and findings are invented to show the shape of the work. Each step used a different technique, and each found something the others could not.
What belongs where
| Question | Technique | Owner |
|---|---|---|
| Does the API reject bad input? | Active API scan on a test backend | Backend team and security |
| Can user A read user B's data? | Manual test with two accounts | Security or QA |
| Are secrets stored in the app package? | Static review of the package | Mobile team |
| Is local data protected on the device? | Device testing | Mobile team and security |
| Do third-party libraries have known issues? | Dependency analysis | Mobile and backend teams |
| What does the app send to third parties? | Proxy observation | Privacy and security |
Old app versions
Mobile apps linger. Users run old versions for months, and those versions call older API endpoints. Your scan should cover them. Keep the endpoint list from each supported version, and retire old endpoints when you retire the version. A forgotten endpoint on the backend is a classic gap.
Certificate pinning and proxies
Pinning stops a proxy from reading traffic, which is the point. For testing, use a debug build where pinning is relaxed under your control. Never ship that build. Record how the debug and release builds differ so you can state what has and has not been tested.
Push and deep links
Mobile apps open links from notifications and other apps. These entry points can trigger actions in the app and calls to the backend. A web scanner will not exercise them, so add them to the manual test plan.
Report honestly
State the scope in plain words: "tested the API used by app version 5.2 on the test backend". Do not say "mobile app tested" when only the server side was covered.
Where Safeguard fits
Safeguard has an iOS app and an Android app, but this post is about testing, and mobile client testing is a separate discipline. For the libraries that mobile and backend code depend on, Safeguard offers SBOM and dependency scanning with reachability analysis, and a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch how an API target is scanned and reported and relate it to the steps above.
Quick check
Can DAST find a hardcoded key in my app?
No. The key lives in the app package, which a network scanner never reads.
Should I scan the production API from a phone build?
No. Use a test backend, a test account and a debug build.
Is a web scanner useful at all for an app that is mostly a mobile client?
Yes, for the API behind it, which holds the data and the access rules. Pair it with mobile-specific review for what runs on the device.
Sources
Last reviewed: 19 October 2026.
