Application Programming Interfaces (APIs) popularity has tremendously blown up due to their increased functionality and ease of integration. This is because APIs are not entirely new concepts.

They have been built on already existing knowledge platform and infrastructure which is web technology. However, approaching API security in a similar way as browser technology would be a grave mistake. Although both share some threats, these technologies are different and as such need to be handled distinctively.

What are APIs?

Since the very early days of computing, protocols such as CORBA, SOAP and even COM+ emerged. However, none of them met the basic programming requirements that are cross-language functionality, simplicity and scale. This is why the World Wide Web became such a crucial tool. It was distributed, scalable with simple yet powerful protocol. As such, developers were able to integrate applications to the web without necessarily having the web server / web browser pairing. And this is how APIs were born.

APIs allow developers to build an open design that makes data and functionality sharing straightforward. The nature of APIs is that they give client-side developers (both legitimate and hackers) a more polished path to access the application. This path exists because APIs have a sort of map that shows the entire implementation of the application. In a web app finding this path would be difficult since it would be buried under panels of web application functionalities. As such hackers have valuable information that could lead them to the core database of a system where messing with data would be a walk in the park. Since APIs are self-documenting and extremely clear, they provide insight that would otherwise be overlooked. In a nutshell, what makes APIs so easy to use and integrate also makes them invaluable sources of intelligence for hackers.

When an API has been well-designed, it brings a lot of powerful tools to the customers, clients and even employees. A good API developer should understand the threat profile of the tool they are developing. Unfortunately, most API developers come from a background of web-design and therefore do not realize that the APIs demand a different approach. When dealing with APIs, hackers and malicious people use three main modes of attack. By understanding them, you will make better, safer APIs.

Threat 1: Parameters

Parameter attacks focus mainly on exploiting data that has been sent into an API. They usually focus on SQL injection, URL, HTTP headers, post content and query parameters. SQL injection is the most common. Parameter attack attempts to trick the system by giving it data to input that will exploit applications behavior and supporting infrastructures such as the database. Hackers can use this vector of attack because many developers neglect to sanitize inputs. In the case of web frameworks, sanitization of input is automatically applied.

Threat 2: Identity

You may be familiar with the concept of user identity. However, APIs have what is called an application identity. This is mainly a unique key that identifies the application calling an API. More commonly known as an API key, it is duplicated all over the application instances. Doing this helps in client management such that a popular application cannot monopolize an API making the other apps perform poorly.

While these are unique keys, they are not authoritative credentials; even though many developers treat them as such. Since these API keys are hidden inside the client application calling code, a good developer can find them and exploit an API giving him/her full access to the system.

Threat 3: man-In-The-Middle

In this kind of attack, the hacker sits right in the middle of the sender and the recipient. This sort of attack can be either transparent or the attacker may pose as either one party or the other. The ultimate goal here being the exchange of unencrypted or unsigned data. APIs that are not properly configured using TLS/SSL are quite prone to this sort of attack. Historically, there have been some challenges regarding the scalability of SSL loads. With proper configuration, these attacks will not be successful. When dealing with APIs, the stakes are higher. Hence, transport layer communication must be secured, or else the whole system is at risk, However, an SSL certificate averts man-in-middle attack by providing authenticity to users means it ensures that a user is dealing with the identity to which he intended to deal with. You can choose any reputed SSL certificate authorities like Comodo SSL certificate, RapidSSL, Sectigo, etc. that can fulfill security needs.

Strategies to mitigate threats

Parameter validation

The first step in confirming the security of an API is ensuring that all incoming data is sanitized and valid such that it won’t cause any harm. The most effective way of ensuring an API is secure is counterchecking all the incoming data against a thorough schema which will have a highly detailed description of what is acceptable and what is not. Data that doesn’t conform to these standards is disregarded. Meaning that, the data input requirements should be as restricted as possible.

Explicit threat detection

There are patterns in everything. Whether it’s a script or SQL injection, they follow some similar patterns which the threat detector can see coming before it hits. Having some specific threat detection technologies in your API will help avoid attacks such as denial of service (DoS). Applying virus detection on the risky encoded content is prudent at this stage. APIs that are involved in file transfers should first decode all the base 64 attachments and then submit them to crucial server grade virus checks. This will prevent any virus passing into your server disguised as an attachment.

SSL Everywhere

Today, SSL is a requirement and not a luxury. Considering the enterprise level transactions being carried out by APIs, it’s wise to apply SSL encryption throughout. The primary function of the SSL certificate is to validate data being transmitted between a client and a server which is inclusive of the extremely important access tokens used during authentication.  

API security architecture

The above solutions work quite well. However, the best way to secure these APIs from the many forms of intrusions is separating API security and implementation into separate tiers. This allows the developer to specifically concentrate on the application side which will involve the functionality and integration. A security specialist can then work on the security aspect focusing only on matters security. This way, the API gets the best of both worlds.

To keep your apps and integrations safe you'll probably find it useful to automate APIs scanning for known vulnerabilities. Sapience tool developed by eTeam engineers can make your life easier. After a quick set up and scan it will generate a clear report with comprehensive and prioritized list of found vulnerabilities. You won't miss important security issues anymore.