CODEWITHSUNDEEP
apirestsecurity
ysimonson
ysimonson

Reputation: 1092

Rate limiting an API with a special exception

I have a webapp that consumes a REST API. I'd like share the API with the wider world, but before doing so, I need to add rate limiting to prevent abuse / high load from buggy clients. I'd like to make an exception for my own webapp so it has a higher limit.

Is there a reasonable way to do this? Not looking for a 100% bulletproof solution, but maybe something that just makes the API a little more difficult to exploit.

Bear in mind that the webapp is publicly exposed, so I can't just rely on rate limiting by API token, since someone could just use the same token.

Upvotes: 1

Views: 244

Answers (2)

basgys
basgys

Reputation: 4400

Since a webapp cannot hide anything to its users, I don't think there is a way to ensure that the application talking to your API is yours.

Everything you can do is security through obscurity, which is by definition unsecure.

EDIT

I would have a solution, still not secure, but that would be an idea.

The first thing is to have two authentication system.

  1. Third party authentication (API token)
  2. Web app authentication (API token + Web token)

Then it's a bit like your idea. You generate a token for each HTTP session. The difference would be that web app (calls authenticate as such) would have a lower limit. (eg. 10k for 3rd party and 1k for web app). The reason why you should decrease the number of calls authorized is because a single HTTP session (1 person behind it) should generates less API calls than a third party app. Is it your case?

Of course the third party application could easily authenticate itself as a web app, but then it would have to renew its session more quickly, so you can monitor the number of sessions per IP. Just be aware that universities and companies are often a lot behind a single IP.

Upvotes: 1

Enrichman
Enrichman

Reputation: 11337

Depends. Do you want to limit everyone or the same user? In then first case just keep track of the time when the last call happened and avoid call in the last 10 secs (or as you wish). In the second case you have to check also the user, keeping track also of the session or the token.

Upvotes: 1

Related Questions