I have faced a problem with securing backend API in case when I can't trust a consumer.

I have a mobile app which uses GPS coordinates. After some calculation app sends GPS coordinates to backend service. I can't find a reliable solution to avoid faking requests from app to backend service. Some user can sniff traffic that goes from app to backend and just fake real GPS coordinates.

Is there any solution how to avoid this type of cheating? Was thinking about end-to-end encryption, but still, since some "secret key" should be stored on client side - it is possible to get it or even change it in order to see http request structure.

  • 9
    You probably can't trust the incoming GPS position either...
    – vidarlo
    Jun 9 '20 at 6:45
  • 13
    This article is of interest to you. If there is a monetary incentive to cheat then people will, and the amount of time they are willing to spend is directly proportional to the money to be gained. eng.uber.com/… Jun 9 '20 at 12:05
  • 2
    Indeed, spoofing GPS is relatively trivial. Jun 9 '20 at 17:16
  • 1
    I'm sure you already know the answer to this at this point :), so gonna go ahead and try to help you with your specific issue here. How about you require your users to send a 5-10 seconds video of where they are along with their face at specific checkpoints on the map? And you don't need them for long, you could automate face (maybe not necessary) and place recognition on them and then get rid of them. More friction for the user, but at least you're being transparent about it. And of course, more work for you XD Jun 10 '20 at 1:06
  • 2
    I can't find a reliable solution to avoid faking requests from app to backend service. Well, there is none. It's sadly as simple as that.
    – Num Lock
    Jun 10 '20 at 12:19

To put it simply: There is NO way

As you already determined, a request can easily be forged. Even if using a custom encryption, your users can decompile your code and find out how it's done.

The only way to prevent users from tampering and decompiling your code is by not handing it to them.

Often this is done by providing SaaS products that run server sided.

All you can do is try to obfuscate your code if you need to serve the application as such.

But note: Security through obscurity is NOT secure.

P.S: Even if your users do not tamper requests: GPS coordinates of mobile devices can easily be spoofed.

  • Fundamentally there is no absolute way to trust client data. But your opinion precludes an array of measures that could be implemented to detect or reduce the risk of receiving fake data. In just about all cases in information security, perfect in unattainable, however well thought out good enough can be just as good and quite doable.
    – Pedro
    Jun 9 '20 at 15:12
  • For the PS, wouldn't it require the client's phone to be rooted in order to spoof the location? Or is that about spoofing the GPS radio signal using a local transmitter?
    – user000001
    Jun 9 '20 at 16:17
  • 3
    @user000001 You can spoof GPS for hundreds of metres around you with a cheap handheld device off eBay. The "real" GPS signal is very weak at ground, and easy to drown out with noise or a replacement signal. Yes, this is a big problem and, yes, infrastructure all over the world relies on GPS and, no, many governments have not adequately considered these risks. Fortunately that is starting to change, but it's slow. Jun 9 '20 at 17:16
  • 1
    @user000001 You don't even need to spoof the GPS signal itself, you can just spoof the location that is determined by the GPS module to other applications. This works like a charm on non-rooted devices as well. Apps like 'Fake GPS location' do this perfectly. Jun 9 '20 at 17:50
  • 1
    @user000001 You don't need to root your device to spoof GPS you just need to enable developer mode. But it's also possible to spoof GPS by running in an emulator on your PC
    – slebetman
    Jun 10 '20 at 9:05

Generally there is no absolute way to do this. You have to consider incoming data as unstrusted.

There's a few things you can do however to rule out obviously bad data. See https://security.stackexchange.com/a/232943/200347 Other answers for that question contain further useful information for the client side implementation, if you control that.


I will go against the grain here and say that there are ways to do this effectively. But it is difficult.

Instead of just sending GPS coordinates to your server by themselves, send it along with a bunch of other data, like nearby WiFi access points, barometric pressure, and data from the magnetometer.

Then you then need to build a type of heuristic to analyze this data. Check the altitude, check the pressure, etc. Compare it with other data you get in similar regions. Make sure the exact same WiFi access point composition is not the exact same as another region across the world. (If it is, immediately ban the consumer).

It might not be 100% fool proof, but if you have enough resources to validate sensor data from the consumer, you can make it very difficult for them to just do a simple GPS spoof.

  • 5
    I disagree. How do you plan to scan all networks at every position around the world? How do you make sure, when learning, that this data is valid and you don't train your network falsely? What would hinder me as an attacker from obtaining the information that you are checking? To cite the National Institute of Standards and Technologies (NIST): "System security should not depend on the secrecy of the implementation or its components." Believe it or not, make it as complicated as you wish. You will be cracked. The best example is Pokemon Go. 30million+ of funds and was cracked in days. Jun 9 '20 at 17:48
  • Like I said, it's not foolproof, but you can make it very difficult. Checking the IP + altitude + pressure + other radio frequencies then build a model. Use machine learning to detect abnormal patterns and ban suspicious activity. Someone attempting to fool this system will need a lot of resources and a lot of trial and error. Of course it can be done, but the security is in making the requirements to circumvent it higher value than the target itself. At the beginning the system will be vulnerable while learning, but should grow more secure over time.
    – 8vtwo
    Jun 9 '20 at 18:18
  • 3
    These are ways to more confidently state that the coordinates are legitimate, but a sufficiently dedicated attacker can still fake these. Indeed, many are not difficult. If your fake coordinates are in your own city then collecting altitude data, barometric data, etc, is quite easy. Even wifi info can be collected or scraped during normal usage of the app, depending on how things work. This isn't to say that I disagree with your answer. Rather, these are techniques to try to determine the likelihood of honesty, and a sufficiently motivated actor may still defeat them. Jun 9 '20 at 23:52
  • 1
    [...] like nearby WiFi access points, barometric pressure, and data from the magnetometer. That data is as easy to spoof as GPS ... or any other data. And things like barometric pressure almost beg for false positives.
    – Num Lock
    Jun 10 '20 at 12:31
  • 1
    The magnetometa-Data is so noisy it can be ignored. Barometric data that's plausible is free from OpenWeatherMap and WiFi Data is free at wigle.net. Extending a spoofing program with this data will probably take me 2 to 5 hours. What it cost you is weeks or months of development, a lot of resources and a lot of angry customers due to false positives. Jun 10 '20 at 14:06

More frequently in the last years, the suggested secure solution to this problem is called remote attestation.

In short, this means running the security-critical parts of your application in a separate area of the CPU that guarantees its integrity (through key escrow on the hardware) and allows a remote server to confirm it.

As far as I know, there's no practical foolproof way of doing it for a independently developed mobile app as of 2020. But APIs already exist to verify the system hasn't been tampered with and as more and more phones include TPMs/TEEs, I think it's reasonable to expect it to be generally available in the near future. It's currently used in Google Pay, for example.

Important caveats:

  • This prevents your application from running on phones that are controlled ("owned"?) by the end user (i.e: rooted/jailbroken phones). It can be considered a form of DRM, and is controversial (see the related secure boot controversy on PCs)
  • You'll need to extend your TCB to include the CPU manufacturers and OS vendor.

People have a wide variety of opinions regarding these caveats, the two extremes being "irrelevant in practice" to "make the technology worse than useless".

  • Not as controversial as you make it sound ... I remember a few years ago some smartphone builders getting sued and punished at US courts - because rooting was considered part of "general use" - but that shifted over the years - and now even phones from good brands like samsung are locked - they make it extremely diffcult to root in the first place - and part of the BIOS contains a fuse like wire connection that will be destroyed when the device detects the rooting - thus marking the device as unsafe for say banking or other secure services
    – eagle275
    Jun 10 '20 at 15:09
  • 1
    1) Set up fake GPS signal emitter. 2) Laugh as "secured" system obediently submit fake data. In the end all your backend sees - is bytes from user's side of the wire. Whatever happens on that side is absolutely out of your control, period. Jun 10 '20 at 20:47
  • @eagle275 agreed, there's definitely been a shift when you consider general practices. I think that is in part related to smartphones shifting from a initial "enthusiast" product to mass marketed to people that don't care about this sort of thing. Jun 11 '20 at 7:41
  • @OlegV.Volkov I wouldn't be surprised to see signed GPS packets in a few decades, as well as "secure" buses between the GPS controller and the CPU! IIRC, some Apple accessories, for example, use cryptographic signatures to ensure you can't replace them. But I agree with you in spirit, there will always be a way to break a system. It's only a matter of how accessible / cheap that attack is. Jun 11 '20 at 7:44

Not "ensure all data", but "reject clearly wrong data"

If the data involved is gps coordinates, then you can keep track of where the user is and thus where it is possible for the user to be given their previous positions. If the user travels faster than the speed of light, then reject that data. If the user is travelling as fast as a plane but is not at the altitude a plane should be at, reject that data. Basically, take into account different modes of transportation, and if the user could not clearly get from where they were at their last data point to where they say they are now, then reject the data.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.