2

I know that appKey is not a means of authenticating applications. But I am wondering what are the best practices for avoiding quota theft for open APIs, that are not associated with any user account. Google Maps API could be one such example of these APIs. Including the appKey inside the clients (browser application, mobile clients) make them vulnerable to appKey theft.

For the reference, here are Google's recommendations: https://support.google.com/cloud/answer/6310037

It could be a wrong assessment, but is OAuth 2.0 Client Credentials flow with a proxy server suitable in such scenarios? Are there any real-world cases?

  • Why not simply encrypt your appkey when storing it? – Limit Jul 18 '16 at 7:51
  • Yes... That doesn't make it a problem at all... Good one. – Adam Sitemap Jul 18 '16 at 9:00
  • 1
    @Limit Where is the decryption key stored? What about MITM? – Noir Jul 18 '16 at 10:11
  • @Noir Ah! Yes. My solution goes out of the window :P – Limit Jul 18 '16 at 10:24
  • @AndréBorie usually you SLA with third party apps, that limits the number of API calls, lets per day. AppKey theft causes the actual client to suffer too. But spikes should be allowed, as some services need them – zeronone Jul 18 '16 at 10:45
3

If you cannot setup user accounts or any other way of identification, which is best practice for every API, you are left with the following:

  • Collecting metrics of number of requests per IP, Subnet, AS, Country
  • Throttling proportionally to the usage while trying best effort not to compromise users who do not abuse the system and providing enough quota to the subnet, AS, country etc. This is because without user identification you will always be unfair when trying to limit by network addresses, as this bit is not identifying any user.

You might need to know what the limits should be by looking at the total number of requests from the country and also on the subnets from the same country, same for AS, subnets etc. This is to provide the best quality service by taking into account these metrics. However this is bad method.

ps. You should really do this per user account. If the account is stolen, you put the policy on the accounts to make it not happen again. Use encryption and so on.

  • Again, you should really think whether a quota makes sense. If API requests are so lightweight (or they can be cached) then you'll spend more money implementing quotas that they'll actually save you. – André Borie Jul 18 '16 at 13:43
  • Cache is not the infosec part. – Aria Jul 18 '16 at 15:53

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.