Introduction

In the 2018 Application Protection Report, we mentioned the potential vulnerabilities associated with application programming interfaces (APIs). These APIs specify how various application components and clients should autonomously interact with each other to deliver the application experience. Through APIs, software services exchange commands and data. Because of this, APIs are tantalizing morsels for predators of the Internet to go after. When attackers breach an API, they often gain full administrative access to the application services within. Making matters worse, APIs are intended for code-to-code interaction, so they often get overlooked in security hardening and software testing. In the past, APIs were uncommon, but their usage is growing alongside the adoption of cloud services, software as a service (SaaS), serverless and mobile computing, and large platform integration with third-party partners.

For our 2018 Application Protection Report, we surveyed thousands of IT security professionals about which applications they deployed via API. The top answers were:

• Office suites — 50%
• Communication apps (such as email and texting) — 45%
• Document management and collaboration — 36%

These are all core, critical applications that manage the day-to-day business of organizations.

API Access Control

Since APIs by their very nature are designed to accept commands—often providing full administrative access—they should require much stronger access control than normal user logins. This means using multi-factor authentication; stringent role-based, least-privilege rights assignments; and detailed logging. In that same survey for the 2018 Application Protection Report, we also asked about API authentication. When questioned if they deployed additional authentication for their APIs, 25% of respondents said they didn’t, 37% said they did “most of the time,” and 38% said they did “some of the time.”

API Security Incidents

We reviewed recent large breaches as well as publicized security incidents associated with APIs from the past few years. It seems there have been a lot of problems, which fall primarily into two large groups of API users.

Large Platforms with Lots of Third-Party Integrations

The first group is made up of the large platform providers who, by virtue of their business models, require rich third-party integrations. Just skimming the names—GitHub, Facebook, Salesforce—reveals the scale and kind of services we’re talking about. These platforms are designed to ingest data for storage, then share and process it with third-party services and customers. Their APIs are truly the freeways into their applications where a bulk of the work flows in and out. The sheer number of systems using the APIs means that the API must manage authentication and access privileges on the scale of tens of thousands of connections and millions of operations every day. The immense stores of valuable data in these application platforms also make them very attractive targets for the entire spectrum of threat activity (crime, hacktivism, espionage, warfare). Listed below are some major API security incidents that have occurred just over the past few years:

Mobile Apps

Very few mobile applications stand alone. Most mobile apps are specialized software clients that query a server over the network to supply data or additional processing for the mobile client. Some of these connections are obvious, like email or podcasting apps, which need remote data feeds. However, there are others such as weather apps (querying a weather service), navigation apps (querying map databases), and even games apps (querying advertising content or multiplayer servers). All these service connections are using APIs from the mobile client to a server or platform online somewhere.

Attackers will often decompile and examine the mobile client to uncover the mechanism used to authenticate and access the API. In some cases, the attacker will even acquire the developer kits and documentation associated with the mobile client or associated libraries to assist in their search for strike points. Shown below are some major mobile API security incidents that have occurred over the past few years:

The number one entry in the OWASP Top 10 Mobile¹⁴ security list of problems is “Improper Platform Usage”. This security vulnerability warns specifically: “Any exposed API call can serve as attack vector here” when “the exposed service or API call is implemented using insecure coding techniques…”¹⁵ The exploitability for this security issue is rated “Easy” and the technical impact is rated “Severe”. As you can see, those warnings were prescient.

Once authentication credentials are stolen, like by phishing, APIs are a great way to silently drain off accounts via bots, like what happened to Binance in March of 2018.¹⁶ No single API user should be able to access thousands or millions of customer records, without at least raising some kind of alarm.

Lastly, many of these API incidents are the result of injection attacks, which continue to be a problem in application security. Injection attacks are a side effect of weak input sanitization that allows attackers to inject commands directly against the application. These vulnerabilities are known, solved problems in application security. We know how to test for them and how to prevent them, yet they continue to occur.

Defending APIs

The first step in defending an API is to become aware of what APIs are in place and what they can do. Since APIs are not user-facing, they can be overlooked in web application security assessments. In many cases, unless you direct the security assessor to the specific API to be tested, they will not get tested. Many APIs often run on alternate TCP ports than the main user web service (80 /443) and are therefore overlooked in the scanning process. Sometimes they’re buried deep in an esoteric URL like http:www.website.com/servicestub/hook/api that isn’t discoverable in a normal web crawl. Even applications that don’t necessarily offer external API services may still have APIs enabled by default within their infrastructure. Modern applications are like onions, made up of many independent layers of services, sometimes in different locations and technological environments. These layers communicate via Internet-accessible APIs, perhaps in ways only known by the developers. Having hidden APIs doesn’t mean attackers can’t find them; attackers are often more willing to invest time and resources to find holes.

There is a second level of understanding your APIs: knowing the permissions and what functions are allowed. Many APIs have identity access management privileges hidden within a configuration setting or even hard-coded into the application. Things get more complicated when software updates can invisibly alter these settings. An API that links a web user interface to a third-party geolocation application may be Internet-accessible and offer root privileges on the web server. Unless you check, you would never know. Furthermore, many APIs either have logging disabled or do not offer security logging features. If an attacker tried to brute force the authentication on an API, would the security team be alerted?

Lastly, all API connections make use of the HTTP protocol and serialization of data. This means the data may not be easily human-readable but it is still decodable if transmitted without encryption.

Given application complexity—not to mention the constant updates—sometimes the most prudent choice is to gate as much of the application as you can with an application-aware firewall that’s configured to allow only the connections that you expect, and to wrap them in transport encryption like TLS. In my experience, it’s often during this firewall deployment process that APIs are discovered—they become restricted by the network access controls and things malfunction. This is often when the developers pipe up with the revelation of a previously undisclosed critical API that ties the systems together. As troublesome as this makes deployments, it’s much better to find these dependent APIs before an attacker does—and you end up a headline.

The API Attack Surface Will Keep Growing

We’re just at the beginning of the hockey stick growth curve of API usage. Technologies such as serverless computing use APIs to tie together large numbers of functions, including storage, message queues, data processing, and library look-ups. This multitude of serverless connections will mean that a single application could have hundreds of Internet-exposed APIs. The growth of IoT devices, single page applications,¹⁷ and mobile applications will also increase API usage, as these are all essentially small, dependent clients calling an API over the Internet.

Regulators are also advocating for more API usage to facilitate open data exchange among businesses and organizations. The US Health Information Technology for Economic and Clinical Health (HITECH) Act encourages accessibility and exchange of Electronic Health Records via APIs.¹⁸ Hospitals, clinics, laboratories, pharmacies, and diagnostic facilities are all building large-scale API connectivity to facilitate this. In the European Union, the revised Payment Services Directive (PSD2)¹⁹ went into effect in January of this year, designed to promote greater banking interoperability. European financial services and payment vendors are leaning heavily on APIs to connect with one another.