What is an API?
If you are not aware of what is an API, I suggest you to go and read this article first and come back.
Did you know that today 83% of web traffic is API driven? I hope you never thought, based on a recent report from Akamai, now more than 83% of web traffic is API driven. This traffic can vary from tech-based companies to clothing stores, etc as many of the organizations rely on a large number of different services that provide using APIs. At the same time, it has increased the attacks against these critical API services. As Gartner has predicted, “By 2022, API abuses will be the most-frequent attack vector resulting in data breaches for enterprise web applications”. Even in recent history, we have heard lots of security breaches related to APIs. Among those companies like Facebook, Equifax, Zynga, etc have paid so may penalties over those breaches.
What is API Security?
As I mentioned above now most of the web traffic is API driven, that’s because the foundational element of innovation in today’s app-driven world is the API. From banks, retail, medical, and transportation to IoT, autonomous vehicles, and smart cities, APIs are a critical part of modern mobile, SaaS, and web applications.
Basically API security is the protection of the integrity of APIs using best practices and products that prevent malicious attacks on or misuse of, them. Given the sensitive data being transferred through APIs, it’s critical to secure them. Increasingly sophisticated attacks occur every year, requiring better security controls and monitoring day by day. Hence this API Security has become an incredibly broad topic as the many different API frameworks, systems, organizations all operate differently.
Why API security matter?
One API security breach can ruin an organization’s reputation in a fraction of a second which took years to build, If you can remember the press buzzing about the recent Equifax high-profile data breach when hackers stole 145 million consumer records? Or maybe you’ve heard of Facebook data leaks that affected nearly 50 million user accounts? API vulnerabilities lie at the heart of these attacks, and both corporations paid a high price for compromising their security such as Facebook lost $35 Billion in market value over the Cambridge Analytica breach.
Many well-known organizations will always become frequent targets of attackers as the value of data being transfer over their APIs has a higher value, such as medical, financial, and personal data for public consumption. Moreover, the majority of them are so miserable that targeted organizations don’t even notice any attempts, but this doesn’t mean you can neglect security. One day, your API might be exposed to serious threats, and the cost of failure will be too high. Once such a breach happens it’s not that easy to deal and recover from it, as it involves lots of costs to bear;
- Investigations, Fines, and Remedy Cost.
- Notification rules and Cost.
- Inevitable class-action lawsuits.
- Inescapable brand damage.
- Looming congressional action.
- Competitive disadvantage etc.
Even if such giants as Facebook and Equifax fail, isn’t it high time you checked your APIs?
Before we dig into more details about the security of APIs, it’s ideal to understand the API protocols, architectures, and Types of APIs, in the following sections let’s looking into those details.
API Architectures and Protocols
An API protocol defines the rules for API calls: it specifies accepted data types and commands. Different API architectures specify different protocol constraints.
In the world of APIs, there are different types of API protocols being used. In the early 2000s — there were only two real API protocols that most developers had to know about: SOAP and REST. But in recent years, however, there has been a proliferation of new types of API protocols, such as RPC, gRPC, and GraphQL, etc. For your reference, I’ll note down small intro to each of the popular protocol types, so that it will help you to understand the stuff that we going to talk about later on this article series.
SOAP (Simple Object Access Protocol)
We’ll start with SOAP, the oldest web-focused API protocol that remains in widespread use. Introduced in the late 1990s, SOAP was one of the first protocols designed to allow different applications or services to share resources in a systematic way using network connections. It is intended to be extensible, neutral (able to operate over a range of communication protocols, including HTTP, SMTP, TCP, and more), and independent (it allows for any programming style).
It’s an XML-based messaging protocol for exchanging information among computers. SOAP’s built-in WS-Security standard uses XML Encryption, XML Signature, and SAML tokens to deal with transactional messaging security considerations. SOAP also supports OASIS and W3C recommendations. SOAP’s built-in standards and envelope-style of payload transport require more overhead compared to working with other API implementations, such as REST. However, organizations that require more comprehensive security and compliance may benefit from using SOAP.
SOAP is mostly used with enterprise web-based software to ensure high security of transmitted data. SOAP APIs are preferred among providers of payment gateways, identity management, and CRM solutions, as well as financial and telecommunication services.
Example: PayPal’s SOAP API
REST (Representational State Transfer)
The term REST was introduced by computer scientist Roy Fielding in a dissertation in 2000. Unlike SOAP, which is a protocol, REST is a software architectural style with six constraints for building applications that work over HTTP, often web services. The World Wide Web is the most common realization and application of this architecture style. Those six constraints;
- Stateless — A REST API is stateless in nature, Client-Server Architecture
- Client-Server — The client and server should be independent of each other. The changes you make on the server shouldn’t affect the client and vice versa.
- Cache — The client should have the ability to cache the responses as this improves the user experience by making them faster and more efficient.
- Layered — The API should support a layered architecture, with each layer contributing to a clear hierarchy. Each layer should be loosely coupled and allow for encapsulation.
REST is considered a simpler alternative to SOAP, which many developers find difficult to use because it requires writing a lot of code to complete every task and following the XML structure for every message sent. REST follows another logic since it makes data available as resources. Each resource is represented by a unique URL, and one can request this resource by providing its URL.
Web APIs that comply with REST architectural constraints are called RESTful APIs. REST by its very nature is stateless and is built in such a way that any web service that is compliant with REST can interact in a stateless manner with textual resource representations. These APIs use HTTP requests (AKA methods or verbs) to work with resources: GET, PUT, HEAD, POST, PATCH, CONNECT, TRACE, OPTIONS and DELETE.
RESTful systems support messaging in different formats, such as plain text, HTML, YAML, XML, and JSON, while SOAP only allows XML. The ability to support multiple formats for storing and exchanging data is one of the reasons REST is a prevailing choice for building public APIs these days.
Example: PayPal’s REST API
RPC (Remote Procedure Calls)
They are the oldest and simplest types of APIs. The goal of an RPC was for the client to execute code on a server. There are two flavors of RPC;
- XML-RPC used XML to encode its calls.
- JSON-RPC used JSON for the encoding.
Both are simple protocols. Though similar to REST, there are a few key differences. RPC APIs are very tightly coupled, so this makes it difficult to maintain or update them. To make any changes, a new developer would have to go through various RPCs documentation to understand how one change could affect the other.
Compared to REST and SOAP, RPC is relatively narrow in scope. It supports a small set of commands and does not offer as much flexibility as a protocol like REST with regard to exactly how you implement it.
Example: Confluence’s JSON-RPC API [Deprecated since Confluence 5.5]
gRPC is an open-source API that also falls within the category of RPC. Unlike SOAP, however, gRPC is much newer, having been released publicly by Google in 2015. (That said, the history of gRPC dates back to an internal project at Google called Protocol Buffers that started in 2001.) It’s a high-performance, lightweight communication framework designed for making traditional RPC calls, The framework uses HTTP/2, the latest network transport protocol, primarily designed for low latency and multiplexing requests over a single TCP connection using streams. This makes gRPC amazingly fast and flexible compared to REST over HTTP/1.1.
Like REST and SOAP, gRPC uses HTTP as its transport layer. Unlike these other API protocols, however, gRPC allows developers to define any kind of function calls that they want, rather than having to choose from predefined options (like GET and PUT in the case of REST).
A key difference between gRPC and REST is the way in which RPC defines its contract negotiation. Whereas REST defines its interactions through terms standardized in its requests, RPC functions upon an idea of contracts, in which the negotiation is defined and constricted by the client-server relationship rather than the architecture itself. RPC gives much of the power (and responsibility) to the client for execution, while offloading much of the handling and computation to the remote server hosting the resource.
By default, gRPC uses Protocol Buffers, Google’s mature open source mechanism for serializing structured data (although it can be used with other data formats such as JSON). Protobufs are language and platform-neutral systems used to serialize data, meaning that these communications can be efficiently serialized and communicated in an effective manner. Additionally, gRPC has a very effective and powerful authentication system that utilizes SSL/TLS through Google’s token-based system. Lastly, gRPC is also open source, meaning that the system can be audited, iterated, forked, and more.
In a way, GraphQL is to Facebook what gRPC is to Google: It’s an API protocol that was developed internally by Facebook in 2013, then released publicly in 2015. As such, GraphQL, which is officially defined as a query language, also represents an effort to overcome some of the limitations or inefficiencies of REST.
When Facebook guys started looking for a different way of fetching data from the server, they were trying to resolve the problem of under-fetching or over-fetching that the existing API protocols had. In REST or SOAP, a request for certain data returned all properties associated with it, even those the user did not need. For example, in REST, if you requested a list of products and their prices, you would also get product descriptions and images, if available. At the same time, if prices were quoted in another source, you would have to make another query to retrieve them. GraphQL was designed to take care of this problem. When you make a data query in GraphQL, you specify exactly what you wish to receive. Such results are achieved through shifting the data definition functions to the client-side, while in REST, data is defined on the server-side. In other words, in REST API architecture, the server defines which data is to be returned, while in GraphQL API, the server only declares the available data, and the client specifies what should be returned. Which means With GraphQL, the clients can get exactly what they want, without having to worry about transforming the data locally after they receive it.
That being said, GraphQL’s benefits are often somewhat oversold. The idea that you never have to version is derived from deprecating fields and replacing them with new ones, which is what REST evolution is concerned with. Thus, you shouldn’t think of GraphQL as “better” than REST or the “next step”, as it is often framed, but rather as an alternative option for a “new relationship between client and data”.
Example: GitHub API GraphQL API
Different APIs feature varying levels of security and privacy, including open, internal, and partner APIs. Multiple web APIs can be combined into a composite API — a collection of data or service APIs.
Open APIs (AKA Public APIs)
Those are publicly available to developers and other users with minimal restrictions. They may require registration, use of an API Key or OAuth, or maybe completely open. They focus on external users, to access data or services.
Internal APIs (AKA Private APIs)
In contrast, to open APIs, internal APIs are designed to be hidden from external users. They are used within a company to share resources. They allow different teams or sections of the business to consume each other’s tools, data, and programs. Using internal APIs has several advantages over conventional integration techniques, including security and access control, an audit trail of system access, and a standard interface for connecting multiple services.
Partner APIs are technically similar to open APIs, but they feature restricted access, often controlled through a third-party API gateway or through a public API developer portal. They are usually intended for a specific purpose, such as providing access to a paid-for service. This is a very common pattern in software as a service ecosystem. While open APIs are completely open, there is an on-boarding process with a specific validation workflow to get access to partner APIs.
Those combine multiple data or service APIs. They are built using the API orchestration capabilities of an API creation tool. They allow developers to access several endpoints in one call. Composite APIs are useful for example in a micro-services architecture pattern where you need information from several services to perform a single task. Using composite APIs can reduce server load and improve application performance, as one call can return all the data a user needs.
Further to the above main 4 types of APIs, there are other various ways where we can categorize different API types; Such as based on data and services, etc. But I’m not going too many details on those as I just want you to understand there are various types of APIs around us, with a different set of needs, constraints, and providing a different set of services.
Hence as you can sense securing APIs become more and more complex and challenging in day by day as the methods, protocols, and types of APIs evolves and changes day by day. There is no single method to secure all of such different API types and protocols, but we shall look into most of the common tactics used in the industry in order to secure them as much as possible in the next articles of this series.
No API can be 100% secure even if we apply all the security tactics that we know of, because in the same way we try to protect our APIs, there are several sets of other people tries to find the vulnerabilities on those methods we use.
I hope I covered almost all the fundamental details you need to know about the APIs before we move into the more details on the API Security stuff. If you have any questions related to this article, feel free to ask anything in the comment section below. Cheers!