Sound application development rests with secure APIs in the cloud

rvlsoft - Fotolia

This article is part of our Essential Guide: Prepare and manage enterprise apps for an IaaS model

Why it's time to implement secure API best practices

APIs are everywhere, and that's just one reason they're so difficult to keep secure. Expert Tom Nolle outlines a detailed, multipart security strategy.

Applications -- even third-party applications -- are increasingly reliant on network-connected APIs to pass work...

within and among application elements. Every API represents a critical feature and potential security and compliance problem. While there have been plenty of new developments in tools to secure APIs, the secret to API security best practices is the process and not the tools. Your first step should be to determine the primary security risks that APIs are exposed to, apply remedies in a specific order to avoid missing some points while overkilling others and integrate security into application lifecycle management to prevent your precautions from leaking away.

The concept of APIs has changed radically since the early days of programming. Today, APIs are network connections to application features or database information, and this new role means that APIs require increasingly stringent security and compliance protection to safeguard the information underneath. Most businesses know this and move to protect their APIs, but few actually manage to close all the avenues of risk by implementing secure API best practices.

Addressing API security risks

We're at the very beginning of a new age in API use, and those risks now need to be addressed. Modern APIs introduce three distinct security risks: unauthorized changes to information, information leakage and interference with legitimate activity. All three are problematic, and all arise from the same source, since networked APIs are often -- by default -- networked for all.

An API today has a network address to allow it to be woven into a workflow, and anyone who knows -- or guesses -- that address can send something to the API. If the request is framed in the way the software beneath the API expects, then the function the API represents will run and something will happen. Information might be returned to someone who shouldn't be allowed to have it, or it could be changed. Even a "garbage" request with the wrong format might still use up processing capacity, creating an opportunity for the API and any applications that use it.

Many users expect to tackle a secure API through the use of a directory or management function that sits between the APIs and the applications that might access them so only indirect and policy-controlled access is provided. The problem with this approach is that it often doesn't actually make the API inaccessible except through the management tool; the API is still a network-addressed entity, and it could be located by scanning IP addresses.

Achieving secure APIs

The most effective API security best practices start with multizone networking. Applications should run inside a secure zone or sandbox and expose only a few service addresses to the outside world. APIs that are not intended to be made available to all should be hosted inside this secure zone. Some hosting architectures, including Docker containers, naturally offer secure zones, and they can be implemented through most private software-defined networking architectures now available. By establishing multizone networking, secure API issues will be significantly reduced.

The next step in achieving secure API best practices is network connection control. Rather than mediate access to the API through a manager, control the traffic to the API's address through network policy management. This approach tests the source IP address of messages, for example, and passes only messages from proper users to the API. There are still ways of bypassing this protection, but it offers the best assurance that APIs won't be accessed by unauthorized individuals; it also offers protection against denial of service attacks on your APIs. It's easiest to apply network connection control to networks that have security zones established, because in-zone traffic is easily recognized. Therefore, only those APIs that are exposed for out-of-zone use will have to be protected.

Network connection control will weed out intruders, but APIs associated with widely used applications within a company might still be accessible to employees who don't have a need or right to the information the APIs represent. API management can "credential" users, and in some implementations, it can also actually redirect traffic, so API messages can come only from the API manager and not directly from the user source of the information. Added to network connection control, that goes a long way toward achieving secure API best practices.

The final step is encryption. If messages to an API must be encrypted, then attempts to access the API directly will not pass the encryption test and will be discarded. In most cases, it's best if the encryption is generated directly by the user of the API and not the API manager. But be sure enough of the message is in the clear to permit the API manager to apply access policies. Usually the IP header is sufficient, but in some cases, a higher-layer header may also be used for authentication. If the information an API manager needs is encrypted, the manager will have to decrypt and then encrypt again, which creates delay.

Implementing all these steps can provide solid secure API best practices, but even enterprises that put all these measures into practice can still find their APIs exposed. The biggest problem occurs with changes to applications, particularly when apps share components accessed through APIs. Component-sharing is a goal of most development teams and aimed at reducing cost and accelerating response to business changes. Sharing API secrets means telling them, and that can mean losing control.

If you have APIs that represent shared application components, consider providing them their own zone or sandbox in your network plan. That lets you apply connection control and encryption selectively to the APIs that require more open use than normal, but which are not published for all. So look at connection control first when planning API security.

The biggest enemy of a secure API strategy is single-mindedness. There's no one strategy and no secret formula. Applying all the API security best practices, in the right order and with the right emphasis, yields the best result.

Next Steps

How APIs can help you recycle code

Here's what you need to know about the API economy

Understand the basics of cloud containers and security

Dig Deeper on Cloud APIs and integration