API threats are all around us. Cyberattacks are increasing, and each day we see new reports of exploits make the headlines. These vulnerabilities could leave a company exposed to hackers, who may leverage APIs to attack and override systems or misuse user data. And as the value of APIs increases in our daily lives, these touch-points are becoming more and more critical.

APIs are also at the core of many mobile apps. Nowadays, thanks to client-agnostic development designs, most mobile apps communicate with an internal API as a backend. But if compromised, such a connection could be disastrous — especially for sensitive sectors, like online banking.

So what are some of the most common threats facing our APIs? Well, OWASP does a nice job of listing the top vulnerabilities in this area. Common issues include injection, broken authentication, data overexposure, broken access control, misconfigurations, improper assets management, and so on.

Interestingly, many API threats boil down to an issue with permissions and access: Who is the requesting party? Are they allowed to access this data? What proof can they offer to prove who they say they are? Many in the API space argue that a greater emphasis on how we handle the client’s identity could help fix a lot of these threats. This is a topic we cover extensively in our eBook, Identity and APIs.

So, in our companion event, LiveCast: Identity and APIs, we brought in two API security experts. David Stewart, Approov, covered what modern API threats and vulnerabilities exist within the mobile spectrum and other environments. Jacob Ideskog, Curity, also traced the history of identity-driven security and examined the role of identity standards within our security measures.

What is API Abuse?

When we discuss API abuse, we mean some sort of unauthorized access with nefarious intent. Hackers abuse APIs for many reasons: it could be to access a bank account and liquidate its contents. It could be to launder illegal funds, scrape data from a retail site, or overwhelm servers.

Seemingly less harmful actions could still impact the business. For example, say a hacker uses an exposed API field to open a new account on a streaming site to capture rewards. A single-use case may not affect things much, but a bot automating this across thousands of accounts could cause serious trouble. “If there is a way to game the system, or cause trouble, someone is going to do it,” said Stewart.

One dark thing about working in API security is that there’s always plenty of examples of hacks to pull from, Stewart jested. Recently, a hacker utilized a “private” Mcdonald’s endpoint to create a map of the restaurants with broken ice cream machines. While this may appear innocent, and pretty funny, it hurts the brand reputation. (Companies often assume undocumented = private, but this is obviously not the case.)

Mobile And Digital Activity Skyrockets

Mobile is a key vulnerability and an important channel to protect, said Stewart — especially since these apps could potentially have access to a lot of business data. Yet, with mobile, it’s difficult to track the source of the caller. “The mobile channel is the hardest API to protect,” said Stewart. “Any API transaction coming in from a mobile app is untrustworthy.”

According to Stewart, it’s important to consider the organization’s identity and not necessarily just who. When dealing with mobile, you must maintain strong API limits, watch out for bots, and prove beyond the shadow of a doubt that clients are authenticated before manipulating user data.

“Even if your API has no vulnerabilities at all, you can still be abused,” said Stewart. Traffic could be emulating a source while not necessarily exploiting a vulnerability in the API. He notices a broad range of scripts and environments used to call APIs. “How can you tell a script is using it, versus genuine API calls?”

The problems around mobile API abuse are accelerating in the wake of the COVID-19 pandemic. A recent McKinsey & Company study found mobile traffic surged to three years ahead of what was projected for 2020. Digital transactions have accelerated across the board, affecting all sectors. Stewart has noticed a steady increase in overall mobile traffic for FinTech, Retail, and explosive growth in Healthcare in recent months (He’s also noticed a significant drop in transportation transactions, which makes sense).

Running parallel to this growth, API abuse within mobile scenarios is rampant. “Abuse has increased proportionally, if not higher,” said Stewart. So how can businesses repel attacks?

5 Step Plan To Protect Mobile APIs

To secure the mobile channel, Stewart recommends a 5 step plan. These security tips could easily be extended to protect other API use cases as well.

1. Block Malicious Bots and Automated Scripts: Bot traffic is the most common mechanism for abusing APIs. To block automated use, protect API keys at scale and prove that it is from a genuine app instance.
2. Reject Apps Running in Compromised Environments: Continually check to see if requests are originating from unsafe environments.
3. Secure API Calls: Use TLS security and follow other security best practices.
4. Authorize User Actions in App Context: Authenticating users is important, but not enough. If you authenticate both user and app, you decrease attack space significantly.
5. Keep Security Capabilities Up to Date with Emerging Threats: Add an over the air capability that scans for environmental checks adds new threat detections automatically.

By following these guidelines, Stewart believes you can cut down the possibilities of what black hats can do by 90%. “You really need to know what is using your API, because that allows you to differentiate between genuine mobile app instances in a good environment versus something which is not.”

Mobile Explosion And OAuth 2.0

Consider how far mobile app development has come in the last decade. If you recall, 2012 really saw an explosion of mobile apps — iOS had about 750,000 apps while Android had around 600,000 apps. Simultaneously, the API universe began to expand. In this period, the client became thinner, and app-to-backend-API communication became very popular for internal and third-party apps.

As APIs grew into the public sphere, 2012 was also the year in which OAuth 2.0 was ratified. The IETF community designed OAuth to be the answer for getting an app to communicate with an API in a way that we know the app and the user. OAuth defines a process of using access tokens to ship this information around to delegate access between parties.

But, as Ideskog described, OAuth 2.0 was not perfect. Access tokens had shortcomings, and the OAuth specification simply wasn’t built for all use cases, such as single-page applications. Nowadays, a client could be a mobile phone, a browser, TV, server, kiosk, IoT device, and other device types, further complicating access management standards. The conditions for each device and service can vary extraordinarily. A banking service may have a very different access management strategy than an open weather API, Ideskog explained.

Thankfully, OAuth offers flexibility. “It’s really designed as a framework,” said Ideskog. “It’s meant to be built upon and improved.” However, flexibility is a double-edged sword…

Specifications Grow

As more companies sought to embrace OAuth, they started complementing it with other specs for other use cases. For example, PKCE, an extension to the Authorization Code flow, along with many other OAuth extensions, have been introduced. Newer projects like OAuth.xyz are informed by a decade of OAuth 2.0 production usage.

These efforts have made OAuth more portable. But, if the OAuth base spec has 30 other interpretations on top, we easily run into interoperability problems. OAuth 2.1 seeks to merge all these relevant specs into one single spec. Bundling them could improve interoperability, which “is important for securing across the industry,” Ideskog said.

+ OpenID Connect For Authentication

OAuth has been critical for delegating access for mobile APIs. However, it leaves out “who you are.” So, authenticators have been a way to answer this question. Methods for authentication include SMS, email verification, Facebook login, and others. Originally, there was no standard that covers all these auth measures.

OpenID Connect has emerged as a way to unify how to start and terminate the authentication flow. It provides a standard way of requesting a login, a standard way of sharing and federating user information while enabling OAuth to work underneath. Having a standard helps cater to multi-factor authentication schemes, which may involve password-less authentication scenarios, like biometrics, keyfobs, or authentication applications.

Hypermedia API-Based Authentication

As Ideskog described, “authentication is a journey of the user.” Even though mobile and other nuanced environments exist, the security space is still hung up on browsers. Yet, mobile developers do not prefer the browser. So, how can we trust mobile apps as we do in the browser?

To build a device and platform agnostic authentication mechanism, Ideskog advocates for hypermedia. Essentially, treating authentication itself as a state machine. Hypermedia, as many RESTafarians know, is the bedrock of true REST APIs. Hypermedia-compliant APIs present links at runtime in the API response, enabling the response to dictate further processes.

If API-driven authentication — or using APIs to solve API security issues — sounds a bit meta to you, you’re not alone. Regardless, this method could be key to improve reusability with a common standard across authentication cases.

Final Thoughts: A Decade Into API Security

Enterprises sure have come a long way in their cybersecurity efforts. Nowadays, securing an enterprise by securing its perimeter doesn’t really make sense. “Where is the perimeter?” asks Stewart.

Now, in 2020, there are an estimated 2.2 million iOS apps, and 2.7 million Android apps available to users. The need for great API security in the mobile sphere has become a ubiquitous concern, and we must start listening to mobile developers.

The pandemic has forced a rise in mobile traffic, and the activities of attackers have increased in tandem. The days of hoodie-wearing solo hackers are over — we now face highly sophisticated, and well-funded cyber attack operations. Applications need security policies in place to pick out spoofing to ensure API requests aren’t just emulating real behavior.

Historically, the rise in mobile usage is intimately tied to both the rise of the API economy and relevant identity standards. But, the concept of a device has expanded. Continued development and education to foster a security mindset will be critical going forward.

With many new devices and varying access processes, the access management standards space has been struggling to keep pace. OAuth 2.1 can hopefully consolidate these new extensions to increase interoperability. Plus, the proposed API-based authentication approach could go a long way toward a reusable authentication template. Thus, truly enabling an any-device, any-auth paradigm.

Free eBook: Identity and APIs

If you want to learn more, consider downloading the free eBook, Identity and APIs. In it, we’ve assembled the top Nordic APIs blog posts on topics like the API Security Maturity Model, OAuth, and OpenID Connect, OAuth flows, handling user identity within microservices, and many other themes.