APIs are the “next frontier in cybercrime.” By 2022, API abuse will be the most frequent and impactful attack vector that involves web applications.

The APIs that feed your mobile apps are rich pickings for fraudsters, scrapers, and criminals. In fact, reverse engineering your mobile app to discover the backend APIs is the first thing any serious adversary would do. Why? Well, more often than not, mobile API protection is inadequate from these types of attacks. You’ve left the door open, and hackers can just walk in and take your data.

In the battle to protect your mobile APIs, the odds are stacked in your adversaries’ favour as your:

  1. Conveniently structured data ensures high levels of scraping efficiency, which lowers their operating costs.
  2. Traditional AppSec toolkit is ineffective – WAFs, rate limiting, JS inspection, etc.
  3. API footprint presents a broad attack surface with rapid development cycles and a long tail of legacy APIs. Let’s be honest: there is most likely a graveyard of tech debt hidden in there with little to no controls in place.
  4. Upgrade cycles for your apps are slower, giving you less opportunity to dynamically defend against fast-moving attackers. 
  5. Visibility of security threats against your API endpoints is limited. The unexpected behaviour patterns of an attack will easily be hidden amongst the noise.
  6. Mobile apps are a low effort / high reward hacking exercise. It’s cheap, easy, and the tools are readily available. 

The API Hacking Toolkit:

The software that your app developers use to design your app can also be used to hack it. It’s a simple process that a junior developer could complete whilst drinking their morning coffee. Here’s what’s needed:

  1. Your app
  2. A Man-in-the-Middle (MITM) proxy: Charles, Fiddler, Anyproxy
  3. An API dev tool: Postman, Insomnia
  4. A mobile emulator or simulator: e.g. Genymotion or BlueStacks 
  5. An Integrated Development Environment (IDE): vsCode, etc.
  6. Cloud infrastructure: Vultr, etc.
  7. Residential proxy: Luminati

If you aren’t defending your APIs from fraudsters, the reverse engineering process takes < 10 minutes or about the time it takes to move on to that second cup of coffee. It’s only slightly more challenging than cracking open the dev console on a web browser and reversing your web APIs.

The Background

For several years now, our customers have been protecting their web apps with Kasada’s JavaScript (JS) based anti-automation solution. Here’s how it works: when a web browser is the expected client for an API, the ability to inspect the client using JS interrogation provides Kasada with a powerful range of detection and mitigation solutions. 

We built our solution on the pillars of:

  1. Sensor detection: Dynamic detection of automation frameworks 
  2. Client-side obfuscation: To prevent our adversaries from understanding — and therefore reverse engineering — our actions
  3. Resource consumption: Penalising bots for consuming compute resource 
  4. Data analytics: A range of techniques that can be applied to data analysis and advanced traffic management policies to add an extra layer of protection

Mobile API Threat Protection - How Kasada API Works

In the face of these obstacles, malicious bot operators have the options to:

  • Engage in a drawn-out battle to defeat the defences. This puts bad bot operators at a disadvantage, as we can read their source code, but they can’t read ours.
  • Identify an unprotected API that provides access to the same data or function, such as your mobile app.
  • Find another website to attack.

If you have valuable data, adversaries will invest time to discover your most vulnerable endpoints. A persistent bot operator has significant resources at their fingerprints and a relatively collaborative ecosystem of like-minded individuals willing to share their expertise.

What is Mobile API Threat Protection?

Protecting your mobile app includes many of the techniques used to protect your website – executed using a native SDK rather than JS.

The primary questions you must ask when protecting a mobile app are:

  1. Is this request originating from the correct application, from a legitimate mobile phone?
  2. Is this a physical device or is it running in an emulator or simulator?
  3. Can we detect human interaction with this device?

From a bot operator’s perspective, plugging emulators or simulators to stop the signal leaks is an extremely challenging task. Generating device and behavioural metrics are equally as challenging.

This forces bot operators to go back to square one: targeting the website with traditional advanced techniques, such as token harvesting, Puppeteer stealth, etc.

Defending mobile apps with long-term efficacy also share many of the same challenges as web protection:

  • Can our detection techniques be reverse engineered?
  • Can we dynamically respond to adversaries?
  • Do we have a range of actions to invoke at the right time? 

The Kasada Difference

We enable our customers to gain insights and visibility into their traffic with almost immediate time-to-value and long-term efficacy while maintaining a seamless experience for their end-users. We have extended the key components of our broader solution and adapted them to the mobile API use case, which includes: 

  1. Our cryptographic challenge is designed to frustrate the fraudsters and provide greater visibility and control of bots. 
  2. Our ability to dynamically interact with the native SDK and change its operating behaviour ensures that we can respond quickly to retooling events and techniques. 
  3. Our ability to leverage data from the device to protect our customers from known and unknown automated attacks.

Summary

Our core mission is to make our customers’ environments hard and expensive to attack. By defending your mobile apps with Kasada, you achieve both of these objectives. This is a low effort / high reward exercise on your behalf that results in a high effort / low reward exercise for your adversaries.

To learn more, check out our API datasheet or request a demo today.