You Can’t Secure What You Can’t See: Protecting APIs

by Joel D’sa and Michael Endler

Last year, it was briefly possible for anyone with rudimentary technical knowledge to upload and host files — including potentially malware — on a .gov website.

The vulnerability resulted in protest posts and pranks but, thankfully, no lasting damage. Even so, as the most devious or most paranoid among you likely already recognize, this vulnerability had all the makings of a dangerous and effective phishing campaign. Given the ability to make malicious payloads appear legitimate, a bad actor could have easily lured unsuspecting users into compromising their data.

The culprit behind this vulnerability? An incorrectly secured API.

Unfortunately, this wasn’t a one-off. These sorts of incidents happen all the time — and sometimes the personal data of millions of users is involved.

A massive amount of data and services is securely and safely shared today through APIs — payment information, banking information, healthcare information, databases of all kinds. APIs are how developers leverage data and functionality to create new applications and plug into digital ecosystems, and they’re crucial to delivering the modern digital experiences that customers and partners expect.

As it’s arguably an imperative for enterprises to expose their services via APIs to remain relevant and competitive today, it’s critical that they do so securely — by controlling who accesses APIs, monitoring and managing how APIs are used, deploying functionality that can spot suspicious behavior and otherwise make monitoring data actionable, and so on. These concepts rely on visibility into API traffic, but in too many cases, enterprises simply do not have insight into what’s been exposed to whom, what is actually happening with the data, and what controls are in place throughout the organization.

The idea of a network perimeter simply no longer applies in a world in which developers agilely and modularly construct digital experiences with APIs spread across multiple environments. Left unsecured, these APIs represent another attack surface — but if enterprises have visibility into all of their APIs and follow best practices for securing them, APIs can not only enable developer productivity but also constitute an important security layer — after all, to control and monitor access to APIs is to establish an important way to control and monitor access to the enterprise’s systems, data, and services.

The stakes around API security are high. Here are some of the key ways enterprises can protect themselves by securing their APIs.

Establish visibility

If a business doesn’t have the proper visibility into what is exposed and how it’s exposed, it’s tolerating a lot of risk and potential liability. It really boils down to the simple fact that a person can’t secure what they can’t see.

Indeed, many other aspects of API security can’t be enabled if visibility isn’t established as a foundation through an API management layer. Are there traffic anomalies, and if so, do they represent a surge in demand for whatever service the API is powering — or do they represent an attack? How often do attacks occur? What are the latency rates and are they changing over time? What IP addresses are sending the requests, and where are they located? Questions such as these, and the actions that follow from them, simply can’t be comprehensively addressed without the comprehensive visibility that comes with managed APIs.

Moreover, having the visibility to answer these questions is only part of the solution. The real goal is to have near real-time visibility and insight that allows IT staffers to take action before the business has been affected — to keep services online and users satisfied. If a team knows an API is failing but can’t discern in the moment if it is dealing with a denial-of-service attack or a systemic issue, that team may have a dangerous hole in its security operations.

All of this reinforces that APIs aren’t just middleware — they are products that developers use to power applications and digital experiences, and like all products, they represent the companies whose data and functionality they expose. All APIs should thus be managed as products — and both establishing monitoring and analytics capabilities and managing for visibility and control are important cornerstones in this process.

Authenticate the right users

Properly-secured APIs should provide authentication for both end users and applications.

OAuth2 is the de facto open standard for API security, enabling token-based authentication and authorization. It enables end users and applications to gain limited, time-bound access to a protected resource without requiring the user to reveal their login credentials. For APIs specifically, OAuth2 allows a client that makes an API call to exchange some credentials for a token, and that token gives the client access to the API.

OAuth2 allows a user to delegate access to their data to a client, such as a web application, that needs this access. The protocol can be configured such that a user can delegate access to a client only for a limited amount of time and only to a restricted amount of API data.

OAuth2 additionally provides a way to delegate access without requiring the user to divulge their credentials to the client. Instead, the client receives a token that enables access to this restricted amount of data and only for the time required for the client to complete the task. For example, if an end user allows her social media account to log into a newspaper subscription, OAuth2 is likely being used to facilitate the transaction, using a token while keeping passwords secret.

There are many benefits to this approach but a key benefit is that if a client is compromised, it will not leak the user’s keys or passwords — meaning that if an attack gains any access, it will be for only a limited amount of time and restricted to a subset of the user’s data.

In addition to authenticating users, OAuth2 also supports the concept of application credentials, which allows an API to verify the calling application before returning a call, thereby facilitating server-to-server transactions. This does not provide absolute protection, as anyone with application credentials can use and potentially abuse them — which is one reason API monitoring and other management capabilities are also needed to keep APIs safe. Even so, application credentials provide an important layer of security, fortifying the flow of trust connecting the end user, the application, the OAuth2 authorization server, and the protected asset the application is requesting via an API.

OAuth2 is made up of a complex family of specs, and there are numerous ways to use it. Many businesses rely on API management platforms to generate OAuth2 tokens, granularly control what a token is allowed to do, and apply concepts such as role-based access control (RBAC), which assigns different levels of API access and privileges based on built-in user types.

The power of authentication isn’t just in controlling who accesses valuable corporate data. Authentication can also be its own source of visibility and an important vector for generating useful insights, such as metrics that segment legitimate users from malicious ones or that capture the IP addresses of all participants in a bruteforce attack.

Don’t turn a blind eye to earnest help

Visibility arises not only from API traffic data but also engagement with the developers consuming APIs. Many security defects are found by well-meaning users, so it’s wise to establish channels that let concerned parties reach out. Enterprises should build a process to ensure IT staffers are able to triage issues, fix them, roll them into production, and communicate with the person who reported the problem in order to verify that the issue has truly been resolved.

Validate input

Input validation helps an application to verify before sending any data that user input matches expected parameters. Applying input validation to APIs is one of the best defenses against SQL injections, cross-site scripting, and other common threats.

Well-designed and managed APIs should leverage an OpenAPI specification or a Swagger spec to clearly define input and output and to deploy APIs with uniform input validation processes. Deploying shared libraries can be an effective way to achieve consistency, and some API management platforms offer policies that enable easy application of input validation.

Like authentication, input validation isn’t just about keeping malicious payloads away from APIs — it’s also about establishing visibility into who is trying to break in and how they are trying to do it. Any user who’s gathering information about an API or trying to break in will likely trip all the input validation safeguards. Imagine a thief systematically checking all the locks on a house, seeing if any happen to be vulnerable. Cyber criminals employ the same technique, systematically exploring APIs to scout for weaknesses. By measuring how many times the “locks” protecting an API are checked and by whom, an enterprise can gain insight into would-be attacks before they start.

Slow attackers with rate limiting

Denial-of-service (DDoS) campaigns and other similar attacks are easy for bad actors to create but rate limiting can help an enterprise to keep attackers in check.

In order to help keep backends from being impacted by unexpected activities, rate limit policies establish thresholds at which spike arrests are triggered. An API team might establish that no one should call an API more than 500 times per second, for example, or that an application be allotted only a certain number of API calls per day.

Rate limits however are only effective against minor spikes in API traffic and have their place in defending some API backends that are particularly sensitive. However, ensuring that your infrastructure, including its services, network, compute, storage and supporting infrastructure can scale out to absorb the increased load of a DDoS attack is really the most effective response.

Rate limits, along with visibility about who is violating thresholds are a great way to monitor misbehaving mobile apps or partner applications. In addition, partnering with your operations team to keep an eye out for increased load on your infrastructure is a great way to gain visibility into DDOS threats. That partnership will be useful to help keep systems online when such attacks materialize.

Leverage self-service for security

Like any product, APIs need a store — a destination where developers can browse APIs, learn about them, and try them out. Providing easy access is both key to empowering internal application developers as well as encouraging adoption among external partners — and providing that access in a secure, standardized way that provides insight into API consumption is a bedrock of API security.

Many enterprises satisfy these requirements with a self-service developer portal that lets users sign up for access, receive an API key, and begin experimenting with APIs — and that gives the enterprise the visibility and control to make sure users don’t have the wrong level of access. In addition to bolstering security, access controls can help businesses pursue monetization strategies through their portals; users of a free API may be entitled to periodic calls, for example, while users of a paid API may be entitled to near-continuous calls.

It’s important to note that metrics derived from developer portal engagement can provide insights into not only legitimate users but also attackers. Bad actors come to portals to learn about APIs, just like well-meaning developers do — but rather than looking for information about how to use the API to build a better application, the bad actors are looking for clues to help them break into the underlying data. If an enterprise knows that an IP address appears to be attacking its developer portal and has also tripped its input validation warnings, the enterprise can feel confident it either has a legitimate user in trouble — or a troubling user up to no good.

Use bots’ weaknesses against them

Attacks from bad bots, such as the brute force denial-of-service attacks mentioned above, are in some ways the cost of being successful in a connected, digital ecosystem. The more businesses use software to automate connections, the more bad actors will attempt to leverage automation themselves. For example, an attacker who has compromised an API key might deploy thousands of bots that pose as “users” trying to buy products, log into loyalty accounts, or impact marketplace rankings and prices.

Though “bad bots” are a threat, many automated programs are “good bots” that are critical to API-powered connected experiences. It is essential that businesses not only manage API keys carefully but also be able to discern from traffic patterns whether API calls are coming from legitimate users or criminals. The ability to analyze traffic in near-real time and to detect and block suspicious behavior may be a crucial component in an enterprise’s security strategy — and one that reasserts the foundational role of visibility into traffic.

Another defense to prevent bots and similar abuse is to put the onus on the client to prove its identity. In addition to authentication, or for calls in which authentication is not optimal, this goal can be served by deploying a system such as reCAPTCHA, which (as some of you have surely experienced) can detect unusual behavior and present a challenge to the user, such as selecting all the images in a group that contain signs, roads or storefronts. For a legitimate user whose behavior has inadvertently triggered the system, reCAPTCHA offers a temporary inconvenience — but to automated bots churning out spam and abuse, the challenge is much greater.

Parting advice: don’t neglect that your organization is unique

As this article has discussed, visibility and the insights it can provide form much of the foundation for API security — but it’s important to recognize that every business employs a unique technology stack that not only raises its own unique security considerations but is also constantly changing.

Many enterprises respond to security concerns by throwing their entire toolset at a problem, but this blunt approach is both inefficient and can risk locking down systems to the extent that vital business opportunities are ignored. Businesses should tailor their approach so that they can respond to problems in a more agile way. Visibility into API traffic enables an enterprise not only to observe, celebrate, and capitalize on the traffic its APIs drive among legitimate users, but also to observe, orient around, and decide how to act against bad actors.

[Looking to learn more about how to make API security a priority? Check out Gartner’s report, “How to Build an Effective API Security Strategy.”]