API Academy

Sponsored by Layer7

API Management 201: API Security

By Ronnie MitraPosted on

Identify typical areas of API vulnerability and learn best practices for securing APIs

In Lesson 103: Choosing a Solution, we discuss the importance of considering functional and operational security characteristics when choosing an API Management solution. Regardless of the solution, understanding the risk profile of APIs is vital to protecting an API against attack. In this lesson, we examine typical areas of vulnerability and share best practices for securing APIs.

Although APIs share a lot of characteristics and underlying technologies with traditional Web sites and applications – and thus share many of the threats that plague the Web – they are fundamentally different and have a unique risk profile, so we cannot rely on the same security methods and technologies that we use to secure the browser-centric Web.

Well-designed APIs are, by nature, more transparent than Web sites. In fact, a good developer should be able to intuit how to use an API simply by inspecting its URL, input parameters and any returned content. This transparency, however, also exposes the internal structure of the backend systems and client apps on either side of the API, providing clues to vulnerabilities.

APIs give client-side developers (and potential hackers) much more finely-grained access into the backend than a typical Web site or application does. Because APIs shift the granularity boundary from relatively-secure internal tiers out to a client application residing on a user’s device, the potential attack surface is significantly increased. 

So, not only do we need to protect APIs from the traditional threats that carry over from the Web but we also need to guard against a new class of risk created by this increased attack surface. In particular, there are three broad security categories organizations that publish APIs need to be aware of:

  • API parameters
  • Identity
  • Cryptography and Public Key Infrastructure (PKI)

API  Parameters

In conventional Web scenarios, parameters (the pieces of data sent to a remote server) are limited and indirect. There are relatively few ways of rendering data and these are subject to the capabilities of URLs and forms.

APIs, in contrast, offer much more explicit parameterization and open up more of the HTTP protocol. This creates a greater potential attack surface, as parameter attacks exploit the data sent into an API – including URL, query parameters, HTTP headers and/or post content.

Typical parameter attacks include:

  • Script insertions, which exploit systems that interpret submitted parameter content as a script (e.g. when a snippet of JavaScript is submitted into a posting on a Web forum)
  • SQL injections, where parameters that are designed to load a certain input into a database query are manipulated to change the intent of an underlying SQL template
  • Bounds or buffer overflow attacks, which provide data beyond the expected type or range and can lead to system crashes or offer access to memory space

Best practices to avoid parameter attacks include:

  • Strictly constraining all the consumer-supplied inputs by default and rigorously validating all data going in and out of an API
  • Rather than using blacklists, creating a whitelist of expected inputs and ensuring these cannot be exploited
  • Taking care to limit error messages and leakage to avoid revealing excessive information about the underlying system


Identity 

Identity-based authentication and authorization is relatively simple on the Web as it is mostly centered on username/password combinations, with interaction limited to a single person’s browser session. With APIs, interactions can include machine identities and multiple identity layers (the user’s logins for various apps and sites, details of various devices etc.)

Consequently, new identity standards have emerged that aim to address some of the complex federation and delegation scenarios common in API-based apps. Of these, OAuth has emerged as the key standard able to solve a wide range of challenges. However, implementing OAuth can be complex for app developers and even for enterprise API publishers.

To further complicate matters, many APIs require client apps to use API keys in order to access their functionality. API keys are unique identifiers that tag onto the end of a query to identify the particular application that is making the call. They do not, however, identify the specific app user; nor do they identify a unique instance of the application.

All this complexity makes APIs particularly vulnerable to identity-based attacks. These attacks exploit flaws in authentication, authorization and session tracking. Many of these flaws occur when poor Web development practices are carried over into the API realm. Typically, risks are created by bad practices such as:

  • Using API keys instead of user credentials. API keys should only be used as a non-authoritative tracking mechanism. Not only do they not identify a user but – because they are often visible in server logs and even included in URLs – they can be extracted by a hacker and cannot be used securely on the client like a password would be.
  • Poor session management. Developers coming from the Web world can be reluctant to include formation credentials on every transaction. Browsers maintain sessions using cookies or other opaque session IDs but APIs rarely take a consistent approach to session management, which leaves developers to create their own methods.

Best practices to mitigate identity risks include:

  • Using HTTPS everywhere – it is not that expensive anymore
  • Making sure API keys, passwords and session IDs never show up in a URL
  • Using OAuth for people or app instances and using API keys only for the app class

Cryptography & PKI

Cryptography is reasonably mature on the Web but it has proved to have surprisingly limited use patterns. With APIs, there is a growing requirement for more sophisticated cryptography. Unfortunately, because so many developers were never trained on how to work with encrypted systems, important best practices are being glossed over. Bad habits include:

  • Risky key distribution practices Sending codes and tokens (API keys, OAuth and JSON Web Tokens etc.) over email
  • Neglected lifecycle management Ignoring or overlooking the formalized method for managing keys

Best practices to mitigate these bad habits include:

  • Using SSL everywhere
  • Not trying to reinvent PKI – it was developed by experts with real-world experience
  • Using hardware security modules (HSMs) to protect critical keys