4

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?

Improve this question
14
  • Why not simply encrypt your appkey when storing it?
    – Limit
    Jul 18, 2016 at 7:51
  • Yes... That doesn't make it a problem at all... Good one.
    – Adam Sitemap
    Jul 18, 2016 at 9:00
  • 1
    @Limit Where is the decryption key stored? What about MITM?
    – Noir
    Jul 18, 2016 at 10:11
  • @Noir Ah! Yes. My solution goes out of the window :P
    – Limit
    Jul 18, 2016 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, 2016 at 10:45

1 Answer 1

Reset to default
5

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.

Improve this answer
2
  • 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, 2016 at 13:43
  • Cache is not the infosec part.
    – Aria
    Jul 18, 2016 at 15:53

You must log in to answer this question.

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