Hello I am working on an Android application in which I'm required to execute a few https web service calls. All my web-service URLs and Web API KEYs are in the code plus the IP address of the server. When anyone does reverse engineering on my app then that guy can get my web service URLs as well as API KEYs then can simply attack using REST client.

How do I secure my setup so that an attacker can't get my WEB API KEY which I defined in the strings.xml


2 Answers 2


It's simple. Never trust the client.

Never rely your business on storing any secrets in the client that the user are not supposed to know.

It doesn't matter whether this is Android, desktop, or whatever. Unless you're prepared to secure your device like an ATM (bolted onto a wall in a weighted safe, and cameras all around), the client is not to trusted. And even if you are on an ATM, still don't trust the device.

How to secure such that any attacker can't get anyhow my WEB API KEY which I defined in the strings.xml

You can't. You don't need to.

Authenticate per user and per device. Users shouldn't be sharing the same API key with anyone else, the API key should authenticate the user or the user's decision rather than the client.

  • I was told you can use API_KEY and add this to header then hit web API. but I got to know hackers can get that API_KEY. Do you know what are the other methods to call rest webservice securely ?
    – N Sharma
    Dec 14, 2014 at 12:30

If you're calling a foreign API (e.g. Twitter) for which your entire app has a single API key, you can either:

  • Share your API key in your app -- a "not-secret secret". It's a crappy situation, and you can obfuscate the key somewhat. But if it's client-side then there's no protecting it. End of story.
  • Keep your API key on your server and proxy API calls. Just make sure that your clients authenticate themselves to your server, or your server will be abused.

If you're instead providing an API that you expect your customers to call in their own mobile apps, then you get to come up with something more secure. An ideal solution is to provide implementors with an API Key Key -- a key for them to generate keys for individual users, rather than a single shared secret not-secret.

  • The best-understood way to do this is to create a PKI. You issue "trusted root" certificates to your app developers instead of API keys. They then in turn use their private keys to sign user certificates, each of which is valid for a single user on a single installation. These can either be short-term session certificates (created when the user "logs on" to the developer's service and valid only for a short time) or they can be long-term (created when the user installs the app and valid for a fairly long time). But as long as you make it understood that the developer is responsible for abuse by any of his users and give him the tools to protect himself, you can let him choose which of these options makes the most sense.

  • A conceptually similar approach is to take the components of a PKI and use them separately. You give the user a "developer key", which he then uses to sign "user keys" using any known mechanism, from as complex as RSA signatures to as simple as concatenating the developer key with a random "user key" and hashing the result. This may be easier to work in to your workflow, but is also probably easier to get wrong. But at any rate, it's probably safer than just sharing the developers API key with all of his users.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .