Web APIs And Security

The security industry marketers recently found a three-letter-acronym useful in pushing their wares. With this follows a panic among those without understanding. The TLA is API. If you are reading this, you probably want an accurate picture before we bite the bare hook that vendors are dangling. So, let’s define API, look at the threats, and define some best practices for building them to be dependable and secure. In later posts there will be some musings about where vendors can help.

If you are not a developer, or even if you know what an API is, for this and other discussions, it will be framed first in this series.

What is API?

The acronym API stands for Application Programming Interface. You may be familiar with a User Interface or UI. A UI is a way for a user/person to interact with software. As the name suggests, an API is an interface that allows a developer to program an application against. That is to say: it is an interface for other software to use.

What is an interface? It is a point of interaction. Like a electrical outlet is a standard shaped place for electronics to interact with electricity. A doorknob is a standard shaped way for humans to interact with a door controlling access to a room.

Often in sales as well as in the English language generalized terms can sometimes be abused in such a way that the meaning becomes fluid. This is often exploited by sales to shoehorn their solution into your org verbally and then leave you to fill in the gaps. To that end, I want to emphasize that the term API refers to a concept that has no restriction to platform, transport protocols, data types, the Web, or the Internet. The fact is that APIs predate the Internet. The concept of an API is two pieces of code interacting with each other and exchanging data.

API refers to a concept that has no restriction to platform, transport protocols, data types, the Web, or the Internet. An API is two pieces of code interacting with each other and exchanging data.

So where does the security risk enter the picture? What could one do with anything that would raise its security profile? Give it the maximum exposure possible. A way to do this would be to build the API so it was available on the Internet. Then use a widely known protocol and standard to document everything about the API that can be interacted with. There are several specific things this could describe, but I specifically mean a Web API with an easily accessible OpenAPI Document.

API Exposure

A Web API is as exposed as it gets, and for good reason. The advantage of a Web API is that it can communicate over the Internet using standard Web technologies. Other methods of API consumption may have entailed referencing DLLs and possibly distributing all the functionality in binary form with the consuming application. Yet other remote API methods may have involved implementing your own version of a proprietary protocol.

Referencing the API over the Web allows for greater flexibility in consumer platforms and convenient consumer onboarding. Several incompatible platforms can share functionality if they talk the HTTP Standard (RFC 2616). Not only do they share code, but code instances and the workloads can be managed, maintained, and scaled in a uniform way. In short: less duplication, less waste.

Security

How does this exposure matter to security? One could say the data is already passing between the browser and server on websites now. Web APIs are no different than webpages when it comes to data. However, there are details about Web APIs that merit special consideration. Let’s look further at Security Considerations.