Securing APIs

APIs are emerging technology for integrating applications using web technology. This approach is exploding in popularity because if builds on well-understood techniques and leverages some existing infrastructure. It is a mistake to think we can secure APIs using the same methods and technology that we used to secure the conventional, browser-centric web. While it is true that APIs share many of the same threats that plague the web, they are fundamentally different and have an entirely unique risk profile that you need to manage.

APIs give client-side developers—both legitimate developers and potential system crackers—much more finely grained access into an application than a typical web app. This is because the granularity boundary for calls to back-end tiers moves from relatively secure internal tiers (those that reside safely in a DMZ) all the way out to the client application residing on the Internet.

The key security risk area that needs to be managed in any API is the granularity boundary. I know, it sounds like architecture geek-speak but a granularity boundary simply describes how much of the back-end systems a calling application can access. Its one of the things I can remember thinking long and hard about in SOA projects over 10years ago, but in those days we did not consider it the big risk it is today. The unfortunate irony is that the same things that make APIs great, also make them a perfect target for hackers.

The problem with APIs is that they often provide a roadmap describing the underlying implementation of an application—details that would otherwise be buried under layers of web app functionality. This can give hackers valuable clues that could lead to attack vectors they might otherwise overlook. APIs tend to be extremely clear and self-documenting at their best, providing insight into internal objects and even internal database structure—all valuable intelligence for hackers.

But increased visibility isn’t the only risk APIs introduce. Increasing the number of potential calls also increases the attack surface, meaning that a hacker simply has more to exploit. Risk increases with opportunity.

A well-designed API enables organizations to deliver powerful web tools directly to their employees, clients, and customers. Good API developers understand the API threat profile. Unfortunately, many API developers come directly from a web design background and may bring with them some bad habits. It’s important to recognize that despite their common roots and sharing of infrastructure, web design and API design have separate goals and demand different approaches.

There are three main attack vectors that hackers target most frequently with APIs. Understanding these will help you to build safer APIs.

Parameters - Parameter based attacks are based on changing the intent of legitimately structured data. Examples of this are URL redirects, query parameters, changes to HTTP headers and or content posted to the API. The most common example of a parameter attack being a SQL injection attack.

Identity - Identity-based attacks exploit flaws in authentication, authorization and session tracking. Usually, this kind of exploit is possible because bad habits from the web world have been moved into the API world.

Man-in-the-Middle - This kind attack is carried out by intercepting legitimate transactions between client and server then applying changes. Often the objective is to gain access to confidential information being exchanged or to alter the transaction for gain. APIs not using SSL/TLS are highly susceptible to this kind of attack.

APIs are a huge opportunity to gain in so many ways through easy quick integration. However, API security, if addressed and defined long before development commences, ensures that business can reap the rewards offered by API technology.