Key takeaways
- A mobile app runs on a device the attacker controls, so every client side defence can be switched off. The detection that counts during a mobile pentest lives on the backend.
- The cheapest server side signal is a valid session token used from a device it was never issued to. The backend only sees it if it records a device identifier or an attestation verdict.
- A standard API access log cannot support a mobile detection rule: it omits the device, the app integrity result, the object owner and the authorisation decision.
- Agree deconfliction before the test: tester addresses, devices and a shared clock. Without it you cannot tell a missed alert from a suppressed one.
- Sort the gaps by the damage each would do against what it costs to see them. Record every decision not to detect, so nobody rediscovers the same gap at the next test.
Detection has to live on the backend
A mobile app runs on hardware the user owns and an attacker can borrow. Every control you put in the client runs on a device the tester fully controls, and each one can be switched off: certificate pinning, root and jailbreak checks, code obfuscation. That is the starting position for a mobile app pentest. The app is not a trusted witness to its own security, so a detection review asks what the server sees once the app's defences are gone, rather than what the app blocks.
The attacks that matter most against a mobile app happen after the tester has defeated the client protections. Bypassing pinning to read the API traffic, covered in breaking a mobile app's certificate pinning, defeats the client and raises no error on the server. The backend still answers a well formed request. If the only record of that request is a web server access line, nothing downstream can tell it apart from a genuine one.
Any signal that exists only on the device is a signal you will lose, because the device is the thing under test. A detection review for mobile starts at the backend and works outward. It asks which of the attacker's moves leave a mark the server can keep.
What a mobile pentest does that the server can see
Set the client aside and a mobile pentest still produces traffic with a shape. The tester replays a stolen token from a machine that is not the phone. Traffic arrives through an intercepting proxy whose TLS fingerprint and headers do not match the shipped app. The app runs on a rooted device that no longer passes attestation. Identifiers get walked to read other users' records. Each of these reaches the backend, and each leaves something a server can record, if the server was built to record it.
The table below is the short list to check first. The right hand column is worth reading twice. In most rows the request succeeds and the application answers it correctly, so the control holds and only the record is absent. The same token theft this list turns into a signal is the one described in what a mobile app leaves on the phone, read here from the defensive side. OWASP places security logging and monitoring failures in its top ten because the record is so often the thing missing.
| Tester activity | Server-side signal | Why it is missed |
|---|---|---|
| Replaying a token from a laptop | A known session used from a new device fingerprint | The API trusts the bearer token and never recorded a device |
| Running through an intercepting proxy | Client TLS and headers that are not the shipped app | Nothing compares the request against the app's normal shape |
| Driving the app on a rooted device | Attestation absent or failed on otherwise valid calls | The attestation verdict is checked at login only, or not at all |
| Walking object identifiers | Many records read in one short session | Each call returns a normal 200 and sits with real traffic |
| Brute forcing an OTP endpoint | A burst of failures against one account | The rate limit lived on the client, which the attacker skipped |
A token from a new device is the cheapest signal
The clearest server side signal a mobile pentest generates is a valid session used from somewhere the app never ran. The tester reads a token off the device and replays it from a laptop. If the backend proves identity from the bearer token alone, the call succeeds. The token is not bound to the device it was issued to, so the server cannot see that the phone changed.
That binding is also the detection. If the backend records a device identifier or an attestation verdict beside each token, a known session arriving from an unknown device is a rule that writes itself. Testing whether the backend enforces any of this belongs to an API pentest, because the flaw and its fix both live on the server. The chain below shows where the only observable moment sits.
The fields a mobile access record needs
A default API access log is a web server format: an address, a timestamp, a method, a path and a status code. It counts traffic. It cannot say who made the request, from what device, running which build of the app, against whose data, and no rule can test a field that was never written. NIST's guide to computer security log management sets out the general field list, and the OWASP logging cheat sheet turns it into concrete events.
For a mobile backend, two fields carry most of the weight and neither is in the standard line. The first is the device: an identifier and the result of a platform attestation check, so a token used from a new device shows up. The second is the client integrity result, which says whether the request came from an unmodified app on an untampered device. The stack below orders one record from the identity down to the authorisation decision, with the mobile specific layer marked.
Authenticated identity
The user or service the token was issued to
Device and integrity
Device identifier and the attestation verdict
App version and build
Client version, and whether it passed integrity
Object and owner
The record touched and the tenant it belongs to
Authorisation decision
Allow or deny, and the rule that decided
Score the test twice, and agree the ground rules first
Deconfliction keeps a defender from spending a night chasing a paid tester. It is also what makes the detection result readable. Record the tester's source addresses, the device or devices in use, the test window and a shared timestamp reference, then keep a note of what fired and when. Without that note, a missing alert and a suppressed one look identical after the fact. A purple team engagement runs this comparison on purpose. Reading it from a pentest costs almost nothing extra.
Ask the tester for a timeline of significant actions with timestamps, and compare it against what your platform produced. Each line lands in one of four places, and each leads to different work with a different owner. Only one of them costs real money. Write the technique names against a shared vocabulary such as MITRE's ATT&CK knowledge base so you can compare this year's scorecard with next year's.
| Comparison result | What it means | Who owns the fix |
|---|---|---|
| An alert fired inside the window | Rule and telemetry both work. Record the time to detect. | Nobody. Keep the rule under test |
| The signal was there, nothing fired | A detection engineering gap, the cheapest to close | Detection team, this quarter |
| The signal was not collected | The app or backend never emitted the device verdict | Product engineering, in a release |
| An alert fired on the tester's address | A rule keyed to the source, not the behaviour | Detection team, before the next test |
Sort the gaps before writing a single rule
A first scorecard usually lists more gaps than a team will close in a quarter, and closing them in the order they were found is the wrong order. Two questions sort the list. What would it cost the business if this were abused for real? What does it take to see it at all? The second question holds the surprises. Emitting a device attestation verdict is a code change with an owner and a release date, while writing a rule over data you already collect is an afternoon's work.
The grid below sorts on those two questions. The bottom right cell is the one teams skip. Writing down that you have chosen not to detect something, with a reason and a date, is a real output, and it stops the same gap being rediscovered at the next test. A penetration test report orders its findings the same way, cheap high value changes first, and it is worth agreeing before the wider method in how a mobile app pentest is run even begins.
Damage if abused
Write the rule now
Real harm and the signal is already collected. Nothing else competes.
Fund the telemetry
No rule until the app and backend emit the device verdict. Needs a release.
Dashboard, not alert
Keep it visible for hunting; an alert here only trains people to ignore alerts.
Record the decision
Write down that you chose not to detect it, with a reason and a date.
Cost to see it
What this means for teams in Dubai and Abu Dhabi
A mobile app that cannot be monitored fails the same expectation whether it ships from Dubai or Abu Dhabi, and what differs is the regulator that reads the gap. A bank or payments app answers to the Central Bank of the UAE, whose information security expectations require security events to be logged and reviewed. A Dubai government entity, or a supplier building an app for one, is measured against the standard published by the Dubai Electronic Security Centre, which asks for evidence of monitoring rather than a description of it.
At the federal level the UAE Information Assurance Standard published through NESA asks the same of sensitive systems, and a healthcare app used in Abu Dhabi also falls under ADHICS. None of these regimes can tell you whether your own backend emits enough for a rule to fire on a stolen token. A dated detection scorecard from a mobile pentest is evidence an assessor in either emirate can read. Where the backend is hosted or operated outside the country, settle before the test which side holds the logs and for how long, because a provider's default retention may be shorter than the window a UAE assessor asks about.
Frequently asked questions
What is detection during a mobile app pentest?
It is reading a mobile penetration test from the defensive side. While the tester attacks the app and its backend, you check whether your own logs and alerts show the activity. Because the app runs on a device the tester controls, the useful signals are server side, in the API and identity logs rather than on the phone. The output is a list of what your monitoring saw, missed, or never collected.
How does mobile pentest detection differ from web application pentest detection?
The classes of gap are similar, but the trust boundary moves. In a web test the browser holds few of the controls, and the client code is still largely the vendor's. In a mobile test the client runs on a device the attacker controls, so root detection, pinning and obfuscation can all be defeated and none of them can be trusted as a signal. Mobile detection leans harder on the backend: device binding, attestation verdicts and token reuse across devices.
Why can't client side protections like root detection be used for detection?
Because they run on the device under test. A tester who has rooted a phone or patched the app can disable a root check, a jailbreak check or pinning, and can also stop the app from reporting that it did so. A signal the attacker can switch off is not a signal. Anything you want to rely on has to be produced and checked on the server.
What backend signals reveal a stolen mobile session token?
A known session appearing from a new device fingerprint, a new address with an implausible location change, or a request that lacks the attestation the real app attaches. None of these are visible unless the backend records the device the token was issued to and the attestation verdict on each call. If identity is proven by the bearer token alone, a replayed token looks exactly like the real user.
Should we tell our security operations team that a mobile app pentest is running?
Yes, for a standard penetration test. Share the test window, the tester's source addresses and the devices in use, and keep a note of what fired. If you specifically want to know whether the team notices without warning, that is a Red Team or adversary simulation objective and should be scoped as one, not read opportunistically from a pentest.
What is device attestation, and does it help detection?
Device attestation is a platform check that reports whether a request came from a genuine, unmodified app on an untampered device. Recorded on each sensitive call rather than only at login, its verdict is one of the strongest mobile detection signals: a valid token arriving with a failed or absent attestation is a clear anomaly. The app cannot be trusted to enforce it alone, so the backend has to receive the verdict and store it.
How long should we keep mobile backend logs for this comparison?
Long enough to cover the test window plus the time to receive and read the report, which is weeks rather than days. Retention shorter than that gap means the tester's timeline arrives after the evidence has expired and the comparison cannot be made. Agree the retention period during scoping, alongside the test dates and the devices.
Can certificate pinning be relied on to stop token theft?
No. Pinning makes intercepting the app's traffic harder, but a tester can bypass it on a device they control, and it does nothing about a token already written to disk on the phone. Pinning and storage are separate controls that fail independently, so neither one substitutes for backend detection of a replayed token.
