How can we prevent fake requests hitting Apigee Edge ?

[adevegowda]

We have seen that sometimes fake requests are being sent and they can be sent in large volumes and cause our resources to exhaust or run out of capacity to handle genuine/legitimate requests.

I know that we can try some the following things to reduce the number of requests made or prevent execution of APIs

1. Invalidate/Revoke the access token
2. Use Quota/Spike Arrest policies to limit the number of requests being made
3. Restrict the requests made from specific IP addresses or range of IP addresses (provided, we know the IP address)

But this will still cause the API requests to hit Apigee Edge and as a consequence the ELBs/Routers/MPs will be utilized to handle these fake requests.

I wanted to know if there's some way to avoid/prevent these fake requests hitting Apigee Edge ?

[gnanasekaran]

Good question @AMAR DEVEGOWDA,

There are multiple ways and combination of several techniques to accomplish this

I think the first pre-requisite to do any of this is to employ a mechanism that will classify legitimate vs fake requests. There are several standard mechanisms

> any standard authentication schemes - basic, oauth, short-lived tokens

will prove legitimate users, but will fail for compromised accounts

> IP whitelisting

not a scaleable option, when you have large number of consumers - might be good enough for system to system APIs

.....

With a layered system like REST - you could easily add a API management layer on top of your existing backend to enforce these constraints and prevent fake requests hitting your backend. This is usually good, since the API management layer [ELB, Router, MPs] are designed to scale easily and handle spikes in traffic well

Now, to your real question - none of these prevent the clients to make a large number of fake requests - so it would be ideal if these enforcements [like the ones you do at the API management layer] can be replicated at several layers that exist between your client and the backend [ELBs, Routers].

Two problems -

1) its not easy to configure all systems to understand and enforce security policies

2) it could become a management nightmare - if you can't centrally manage these enforcements

so what we need to think about is,

1) how can we make the classification of fake vs legitimate, so simple that any layer can easily enforce

2) how can we discourage or make it really harder for fake clients to generate large number of requests, and even generating them is prohibitively expensive for them

One of the approach we are working on is 'proof a work' based model - where a client request need to accompany a 'proof of work' that is hard to compute [several cpu cycles for eg,] and very easy for the layers to verify. The 'proof of work' also need to be reasonable for a legitimate client while prohibitive for a fake client trying to make large number of requests. It is also built on standards so any layer would be able to classify easily legitimate vs fake. You could also add additional security layers on top of this scheme.