Two particularly challenging forms of API abuse are Aggregation and Cheating as a Service. In both these cases your own users are enabling and sometimes funding the individuals and organizations abusing your APIs.
Aggregation apps present their users with data scraped from multiple companies offering competing services or products in markets such as retail and mobility. This form of API abuse is an issue for anyone who wants to control how their users interact with their product or service. Aggregators not only scrape the data provided by an API but can also make requests through to the backend service in exactly the same way as the real app, meaning that your customers potentially only experience your services as presented in the aggregation app.
For smaller companies aggregation may seem like a good thing. Cooperating with aggregators can bring new users to your service, however you will never have control of either your data or your income stream. Aggregation apps offer little guarantee about how your service is presented in relation to your competitors which dilutes your brand and potentially costs you customers.
Aggregators are particularly active in the Mobility as a Service sector where they bring together all of the car and bike share services for a particular city. For various reasons, not least that many of the companies involved are actually owned by competing car manufacturers, most car share operators do not willingly cooperate with the aggregators. This results in an endless game of cat and mouse where operators must continously increase the security of their apps and APIs to counter the ever more intense reverse engineering efforts of the aggregators.
This battle can usually be seen in the aggregator apps themselves where the degree of integration varies with each release. Some operations require you to install the operators app while others are entirely integrated. Most worryingly for operators is when aggregators work out how to enable car unlocking and engine start from within their app.
This form of API abuse rapidly becomes widespread on any platform where users interact with apps to earn rewards and is particularly damaging where this mechanism is a core part of the business model. Typically, mobile games are the most visible platforms open to this sort of manipulation where users take advantage of scripts or websites to automate the collection of points which the user can then translate into in game rewards or power ups. Clearly this is bad for other players of the game, who may just leave the service, and reduces the amount of in game time spent by those cheating, potentially reducing advertising revenue.
For other types of apps leveraging gamefication the practice can have more direct consequences. Social networks, such as Nimses, discussed previously, use a virtual currency, which can be exchanged for real world goods and services, to encourage interaction between users.
Location based marketing apps provide rewards for users physically walking around retail outlets. Websites are available which allow users to login with their own credentials and then send spoof data to the API making it look like that user is walking around stores. Moreover they also make use of entirely fake accounts to further accelerate a user's accumulation of rewards through referrals or transfers depending on what the platform supports. When this practice gets out of hand it is bad news for the marketing service as their customers will not see the footfall they are expecting for the number of rewards that are being redeemed.
Throughout these API abuse case studies we have seen a well established trend of accelerating sophistication in the tools available to would-be API abusers. These include:
This means that the technical effort threshold required for these attacks, even against well protected APIs, is dropping rapidly. Therefore, more services will be vulnerable as it becomes worthwhile to reverse engineer and abuse them even for relatively little gain.
When considering defensive approaches for bot mitigation keep the following in mind.
Taking these steps will dramatically reduce the API abuse you can expect in addition to securing your API and app against more traditional network attacks.