Let's assume I have a mobile app that fetches the news feed from an url on my server.

GET/ https://example.com/api/v1/newsfeed

Is there a way to restrict the access to this endpoint to only from within the mobile app, not other sources souch as a script (Python, NodeJs,... ) or software (Postman, Browser....) ?

I assume that this url should be compiled in binary and since the request is secured (https) packet sniffing software will only reveal the base url (example.com in this case) and the endpoint & body will be encrypted.

But I assume that there still ways to know this endpoint. I suspect two possibilities

  1. Installing a thrid party certificate on the mobile phone to decrypt the packets
  2. Using a decompiler

I just have a rough idea but I am not sure about the technical feasibilities of these two methods.


You can mitigate the threat of your first possibility by implementing certificate pinning. This will prevent a third party cert from being issued and trusted by your APP.

In terms of decompiling you could try obscuring the URL, but dynamic analysis would still be able to eventually find the URL.

You may want to perform a check on the server side instead. Have the server issue a challenge, and the client does some work to create a response to the challenge. That may increase the difficulty of any exploit written.

One simple solution is to check for the header of the request and make sure things like the user agent and other attributes match what you expect.

| improve this answer | |

Have the application register with the server - securely store a secret on the device as part of the registration process. This only addresses a decompiling the apk

As far as the protocol is concerned it doesn't matter if its Python or a Device its all the same where it reaches the other end.

If an attacker has physical access to the unlocked phone or can install anything on it - no controls matter. The user account is breached and they can call that API.

| improve this answer | |

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.