Akamai Blog | The Dark Side of APIs: Part 1, API Overview
API overview
Application programming interface (API) is a software design approach that 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; that is, 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 in the API Evangelist / History of APIs. Many experts consider that modern APIs were born in the 1990s, during the 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 the de-facto standard, since it offered simple API integration and rapid API development, by using standard HTTP messages with XML and/or JSON message formats as a means to easily exchange data between systems.
There is a chart on Google Trends that 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 third-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 by 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 consume and share data among Salesforce and third-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. APIs have helped some of the best known companies’ business models flourish, including eBay, Facebook, Twitter, del.icio.us, Flickr, Google, and Amazon's Cloud Computing. Today, APIs are everywhere and are intertwined with the Internet of Things, 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. 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 the 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 simplicity that makes APIs attractive to developers also makes APIs an attractive target for attackers and makes them easy to exploit.
APIs as seen on the Akamai Intelligent Edge 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 Edge 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, which that is one-quarter of total web transactions that reached origin web applications. We speculate that the numbers may be even 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. Comparing this number against a previous dataset (which showed 65% of API traffic from mobile clients) 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, then 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, followed by XML, then all others. When it comes to standard web form requests, we expect 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 a deep inspection of the incoming API calls and an understanding of 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 and open, and yet extremely powerful. Traditional web applications aren’t going anywhere because humans will always need them, but APIs will continue to be developed to solve countless needs.
In upcoming blog posts, we will take deeper dives into the top three threats to APIs: denial of service, application layer attacks, and credential abuse campaigns.
Acknowledgments
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.
