A mobile security team should evaluate location integrity by testing whether a solution can tell a genuine position from a manipulated one in the flows where location changes a decision, and what happens when the evidence disagrees. Judge three things: which signal sources are read and kept apart, how conflicting signals map to decisions in each business flow, and how consent, data minimisation and legitimate travel are handled. This guide covers Android and iOS apps, each scoped separately. It does not cover fleet tracking, which belongs to device management. Otukan detects location spoofing inside your app and hands the evidence to your backend.
Background on the control itself is covered on location spoofing detection.
Signal sources
Location evidence comes from different layers, and each layer can mislead you in its own way. Keep them apart during the evaluation so that one weak source never decides for the others.
Device position
- Which position sources does your app rely on: satellite fix, network-assisted fix or both?
- On Android, does the solution recognise positions supplied by a mock location app chosen in developer options?
- On iOS, does the solution use the source information the system attaches to a position, which shows whether it was simulated by software or produced by an external accessory?
- How are positions treated on a rooted Android device or a jailbroken iOS device, where location services themselves can be altered?
Network geography
- Does your backend compare the device position with the geography of the request’s IP address, and which team owns that comparison?
- How are VPNs, carrier gateways and roaming handled, given that each can place an honest user’s address far from where they stand?
Spoofing indicators
- Which tools does the solution identify: mock location apps, hooks that rewrite coordinates, emulators, instrumentation frameworks?
- Are indicators reported separately from the position, so your backend can weigh them?
| Signal source | What it tells you | Typical honest misreading |
|---|---|---|
| Device position | Where the operating system believes the device is | Indoor drift, weak satellite fix |
| Network geography | Where the request appears to originate | Corporate VPN, carrier gateway, roaming |
| Spoofing indicators | Whether the position is being manipulated | Your own testers using developer tools |
How Otukan answers. Otukan checks location integrity while your app runs. It recognises mock location providers on Android and reads the system’s simulated-position indication on iOS. It detects instrumentation that rewrites coordinates and emulators that replay scripted routes, and it treats rooted Android and jailbroken iOS devices as context. It also flags the proxies and VPNs that make network origin disagree with position. Each indicator reaches your backend as a separate runtime threat signal, apart from the coordinates, so your server weighs it against network geography with its own rules.
Decision scope
Location only matters where it changes an outcome. Start from the business flow, then decide how much disagreement between signals that flow can tolerate.
Map flows to tolerance
- Which flows depend on location: regional content rights, delivery dispatch, shift check-in, transactions limited to a territory, offers tied to a venue?
- For each flow, what does a wrong approval cost, and what does a wrong refusal cost?
- Is the geofence a hard boundary set by regulation or a soft one set by commercial preference?
Conflicting signals
- What should the flow do when position and network geography disagree but no spoofing indicator is present?
- What should it do when a spoofing indicator is present but the position looks plausible?
- Which decisions stay on the server, and which may the app enforce on its own when the device is offline?
Location scenario matrix
| Scenario | Example | Starting response to adapt |
|---|---|---|
| Consistent position, no indicator | User at home inside the permitted region | Allow |
| Position and IP disagree, no indicator | User connected through a company VPN | Allow and record, or request a fresh fix |
| Indicator present, plausible position | Mock location app active near the boundary | Restrict the location-dependent action |
| Indicator present, impossible movement | Position jumps between countries within one session | Refuse and flag the account for review |
How Otukan answers. You choose the in-app response for each flow: observe, warn, restrict or terminate. A territory-limited transaction can be refused while browsing on the same device carries on untouched. Your backend receives the signal and keeps the final say, so step-up checks and refusals follow your own risk rules.
Privacy
Location is personal data. A location integrity control should let you collect less of it, not more.
Consent and minimisation
- Does the app request location only in the flows that need it, and at the lowest precision that works? Android and iOS both let users grant approximate rather than precise location.
- Does the integrity check send coordinates off the device, or only a verdict and its indicators?
- How long are location records kept, and who can read them?
Travel and error recovery
- How does a traveller, a user near a border or a user with a poor fix recover from a refusal?
- Can support staff see why a decision was made without seeing raw coordinates?
- Have you run legitimate travel, roaming and VPN tests alongside spoofing tests, on devices you own?
How Otukan answers. Otukan reports integrity indicators rather than building a location history. The fields that leave the device are agreed with you during the technical review, so your privacy team can approve the data flow before rollout.
For trip location in travel and mobility apps, see travel and mobility application security. For the wider evaluation, see the mobile app security evaluation checklist. Guides for related decisions are on the other solution guides. If your app is already live, the free App Exposure Check reviews its public store release before your first call with us.