2017 has seen our customers tackling a wide range of abuse and misuse of their Mobile APIs. We are seeing multiple approaches where the business process transparency provided by APIs has resulted in exploitation. Time for a retrospective...

2017 was a busy year for us and our customers battling to hold back the tide of innovative approaches to misuse and abuse of mobile APIs. I thought that this would be a good point to write a couple of short blogs summarizing the range of threats we have seen in the wild in an attempt to categorize the kind of issues you should be looking out for as you build or expand your API based business in 2018.

Over the next couple of blog posts I will cover the following 5 broad categories of abuse:

Aggregation - Your data is aggregated with that of others as part of a commercial enterprise without permission.

Cheating as as Service - Web apps that allow users to cheat gamified and rewards based platforms.

Each category will be defined with concrete examples (where I can talk about them, some instances are under NDA) including how the abuse works and the impact it has on the business providing the API. Mitigation and protection (spoilers, use Approov) will also be discussed.

Business Level Attacks

A common thread we have identified is the idea of the Business Level Attack. This sort of threat is different from typical attacks against internet facing systems as it does not look for implementation issues to exploit but instead uses legitimate access to business logic and data in unexpected ways to the detriment of your business.

This is a particular issue in mobile since an API provides a window into your business operations and
anyone can download your app and reverse engineer how your API works. Compared to typical Web interfaces, the mobile API tends to reach a lot deeper into systems without the mediation of a business logic layer allowing access to unfiltered raw data which can then be reused far more easily. Given this high level of visibility into your operations, if your system can be exploited for gain, someone will find a way to benefit from your work.

To make matters worse, it is often your own customers and users who are actually performing the attack (unwittingly or otherwise). Since this traffic is coming from authenticated users and typically will consist of well formed and legitimate API requests, your Web Application Firewall will be of little help.