APIs Considered Harmful

There has recently been a lot of attention (because of some recent news stories) about the security of APIs. (Or really - lack of security.) Especially, about APTs having success using them as attack vectors. So, really no surprise here, as an API is part of the attack surface of a system, typically, an application. (But it is somewhat of a surprise as APIs are not a new thing, and they were not at all on the security communities radar - including my own.)

Certainly over the last few years, the number of systems that provide APIs have expanded greatly, towards the goal of opening up functionality to other systems to make their system more useful to customers. Fundamentally, an API is just another interface (the “I” is for Interface) into a system – So it needs to be protected.

APIs can provide a wide variety of functionality – E.g.,

1. Pull data from the system
2. Push data into the system
3. Manipulate data inside the system & system functionality

Here are some basic requirements for a Secure API that I have thought of that system (application) developers should consider -

1. APIs should not be enabled by default; it should take explicit action by the system administrator to open an API for use
2. Do not expose an API externally, unless it is a Secure API and absolutely necessary, (per above) as it increases your attack surface
3. Do not expose your API internally, unless it is a Secure API and absolutely necessary, as it increases your attack surface
4. If an API is exposed, then limit the exposure to only those other systems that need access to the API
5. Systems that provide APIs should provide security controls on the use of the API. Think, all the standard things - like what I call the “The Big 3” - AAA – Authentication, Access Control, & Auditing
6. Do not assume that only trusted entities will attempt to use an API (yeah, a bit of paranoia on this is useful) or that only trusted systems will know how to use an API
7. Consider how the API can be misused, abused, or otherwise taken advantage of - I.e., Think like an attacker.
8. Perform penetration tests on your Secure API.? APIs can have coding errors, so they are subject to the vast number of already known software attacks, such as buffer overflows, etc.
9. Avoid complicating the situation by adding unnecessary new technology. E.g., I can envision an enterprising startup creating an “API Firewall”. This should not necessary.

The developers of APIs know their API’s functionality, their issues, and weaknesses. They should be the first ones to be asked (about their API): “Where are the problems, weaknesses, areas for abuse, misuse, etc.?” They will gladly tell you. (In my experience, they have already been documented in bug reports, but not acted on because they are given low priority, so they never get addressed.) You just need to ask them, as it is likely that they have been complaining about them for a long time.

Above I used the phrase “Secure API”, as opposed to just “API”. This should be a new term in cybersecurity that denotes that the system developers have taken all necessary precautions to secure their API.

As we experience more attacks on APIs, we should look at their root cause and adjust or add to the above requirements that should be considered and applied to APIs.

The above are just a few ideas for developers to consider.?

I am sure the list is not complete, so feel free to add your ideas in the comments.

Postscript -

Add to the above list -

10. Inventory your APIs - So you know what you have and what needs to be managed