_Ryan Barnett, Principal Security Researcher, Akamai_

_Elad Shuster, Senior Security Researcher, Akamai_

### 

**API Overview**

Application Programming Interfaces ([API]()) are a software design approach which enables software and system developers to integrate with other systems based on a defined set of communication methods. APIs serve as software building blocks and allow for software reuse – essentially allowing fast development of new systems based on existing capabilities.

APIs have existed since the dawn of modern computing, and are constantly in use by software libraries and frameworks, operating systems, remote system communications, web applications, and, most recently, mobile applications.

APIs can be private – i.e. for internal use within a system, a company, or between two parties that agree to communicate via APIs. Alternatively, they could be public, which means that the person or company that offers the API makes it available for general use.

A detailed history of APIs in the modern age can be found here: – [API Evangelist / History of APIs](). Many consider that modern APIs were born in the 1990’s – 2000, during the SOA (Service Oriented Architecture) movement. In fact, APIs were first referred to as “Web Services”, which Wikipedia [describes]() as “a_ standardized way of integrating web-based applications using the XML, SOAP, WSDL and UDDI open standards over an Internet protocol backbone. XML is the data format used to contain the data and provide metadata around it, SOAP is used to transfer the data, WSDL is used for describing the services available and UDDI lists what services are available.”_

While “Web Services” provided a standardized way to integrate web based systems, their adoption was slow and took place primarily in enterprise software and systems. Slow adoption rates may be attributed to the rigidness of the related protocols and message formats. This changed with the introduction of RESTful APIs. The [RESTful]() approach for APIs quickly became a de-facto standard, since it offered simple API integration and rapid API development, by using standard HTTP messages with XML and/or [JSON]() (JavaScript Object Notation) message formats as a means to easily exchange data between systems.

The following [Google Trends]() chart shows how the popularity of different technologies has changed over the years.

_ _


With the introduction of mobile applications in recent years, API adoption skyrocketed. The chart shows that these modern technologies exploded after the introduction of the Apple iPhone back in 2007. APIs offer mobile application developers a way to rapidly and easily integrate 3rd party data into their apps. Today integration of mobile apps with social networks, mapping services, and payment services is a minimum capability expected of any app. This is a direct result of the wide success and adoption of APIs. Many recent studies and publications, such as [Tracking the Growth of the API Economy (Art Anthony)]() all point to the rapid growth in Web-based APIs in recent years.

One of the first companies to offer robust and elaborate APIs was Salesforce.com, which launched its set of APIs in 2000, allowing customers to share and consume data between Salesforce and 3rd party applications.

Within a few years, all major sites and Internet-based companies started exposing APIs in order to offer their software and data as a service to customers and third party developers. Some of the best known companies whose APIs helped their business model flourish are eBay, Facebook, Twitter, del.icio.us, Flickr, Google and Amazon’s Cloud Computing. Today, APIs are everywhere and is intertwined with the Internet of Things (IoT) where just about every device with an internet connection is talking to a back-end API.


No overview of APIs is complete without a demonstration of what a simple API transaction might look like. Let’s consider a mobile application designed to suggest the proper type of clothes to wear, based on the current local weather. In order to get constant weather updates, the mobile app developer integrates with a weather API service, which offers a simple JSON response for an API call that includes the city name.

A possible API call from the mobile app to the weather service might look like this (notice that API call parameters are embedded into the URL)

GET /APIKEY/geolookup/CA/San-Francisco/Units/F/getWeather.json HTTP/1.1

Host: api.some_weather.site

Connection: Keep-Alive

The response to this request would be:

HTTP/1.1 200 OK

Date: Wed, 25 Jan 2017 13:13:46 GMT

Content-Length: 140

Connection: keep-alive

Content-Type: application/json; charset=UTF-8

{

“status_code”: “success”,

“location”: “San Francisco, CA”,

“High Temperature”: “87”,

“Low Temperature”: “59”,

“Units”: “Fahrenheit”

}

The RESTful approach to calling the API is extremely simple to understand, even without proper documentation. Many developers would find it easy to modify this API call in order to query for weather data on any other city they wish, with minimal code changes. The same design can be seen in the API’s response, which uses a JSON message format that can easily be consumed and parsed by all modern web and mobile frameworks, without any additional development overhead. This simplicity and open nature of APIs are a primary reason for their proliferation; however, as with all other aspects of software design, without proper security, APIs can be abused. The same simplicity that makes APIs attractive to developers also makes APIs an attractive target for attackers, and makes them simple to exploit.

**APIs As Seen on the Akamai Intelligent Platform**

In order to learn about the adoption and use of APIs across the Internet, we decided to use Akamai’s [Cloud Security Intelligence]() (CSI) data analysis engine . CSI is a unique data processing engine within the Akamai Intelligent Platform, used to continuously analyze approximately three Petabytes of data related to web security threats per month. From observations of 144,713,265,352 (144.7 Billion) HTTP transactions (going to the origin web application) on a given day, the system identified 36,593,891,540 (36.6 Billion) API transactions – that is one quarter of total web transactions that reached origin web applications. We speculate that the numbers may be higher than 25%, however, we used a conservative detection approach to identify APIs.


A closer look of these API transactions revealed that 38% of the API calls were performed by mobile clients. When comparing this against a previous dataset (which showed 65% of API traffic from mobile clients), this supports our assumption that mobile applications are among the biggest drivers for API development and usage.  The distribution of APIs across industry verticals shows that High Technology companies are at the top of all API calls, Other Digital Media is next, followed by Gaming and Retail.  Another interesting piece of data observed during our data gathering process was the difference between an API call (HTTP request) message Content-Type, and the message Content-Type of standard web traffic:  It is clear that JSON is the preferred API call Content-Type among API developers, with regular Form-Data ( “application/x-www-form-urlencoded” ) behind it, XML and all other. When it comes to standard web form requests, it is expected to see that clients are mostly sending message bodies by using URL-encoded Form-Data. This difference in message types is critical when it comes to protecting API traffic against attacks. Protecting APIs requires deep inspection of the incoming API calls and has to understand the relevant API protocols. Only by fully supporting API message parsing will the protections be able to pinpoint malicious payloads within these messages.

**Conclusion** APIs are everywhere. They are simple, open and yet extremely powerful. Traditional web applications aren’t going anywhere as humans will always need them, however APIs will continue to be developed to solve countless needs. In the following blog posts, we will take deeper dives into the top three threats to APIs: Denial of Service, Application layer attacks and Credential Abuse campaigns.

**Acknowledgements** The research and data presented in this document was originally drafted by Ory Segal, with data collected and analyzed together with Or Katz and Aharon Fridman.

Read More