New Challenges in API Security
Author: Tzury Bar Yochay, CTO and co-founder, Reblaze
For many organizations today, APIs are important parts of their online presence. However, as API usage has grown, hackers have begun to wage concentrated attacks upon API endpoints. Securing them has rapidly become a crucial requirement. Unfortunately, API security can be problematic. When compared to web applications, APIs have many unique challenges. As a result, traditional web security solutions are not able to fully protect APIs.
API security versus web application security
APIs and traditional web applications have a number of important differences.
Complexity. Web applications usually offer a limited number of possible user activities within the browser. In contrast to this, APIs are constrained only by their developers’ abilities and ambitions. Modern systems have become very complex, and APIs often support hundreds or even thousands of functions. Meanwhile, programmers are under constant pressure to expand their capabilities and deliver new releases ASAP.
Broad attack surfaces. A large API usually offers opportunities for abuse that were unanticipated by the developers. Furthermore, most programmers do not think in terms of vulnerabilities; their focus is on expanding the feature set, and they rarely spend time exploring their existing codebase for potential flaws. Hackers think differently: they look for ways to exploit APIs.
Division of labor. Modern APIs are usually the work of a large team. Different developers are responsible for different products and different parts of the API. It is often difficult to coordinate everyone’s efforts and ensure that best practices for security are consistently followed.
Unlimited size. Web applications have well-defined capabilities, but there are no inherent limits to how large an API can be. To maintain tight security, it is best to restrict an API 
to the minimum functionality possible. But developers and product managers have the opposite goal: they want to expose the broadest API that they can. This tension often produces a non-optimal security posture.
Structure. A basic principle of security is “least privilege”: every user of a system should have only the minimum amount of permissions and access necessary to accomplish their goals. It is straightforward to restrict privileges for users of a web application.
However, as APIs grow, they often offer more and more functionality to the same class of users. Often, they are not designed with the necessary granularity for correctly controlling access to an expanding featureset.
Summary: For these reasons and more besides, API endpoints can be challenging to secure. This is why most web security solutions have trouble doing so effectively.
How to evaluate a security solution
Here are some criteria for evaluating a security solution’s ability to prevent API abuse.
Flexibility. Most WAF (Web Application Firewall) appliances are designed to be used in a “castle and moat” configuration. In this approach, the data center is the castle, and the WAF is the bridge over the moat. It’s assumed that incoming traffic will always pass through the WAF in narrowly defined ways over certain ports (e.g., ports 80 and 443, for HTTP and HTTPS), so the WAF can control access.
In contrast to this, API security requires much more flexibility. APIs can use a variety of ports, and a variety of protocols. And they tend to expand over time, which requires a security solution that can adapt appropriately.
Dependence on environmental detection. In traditional web application security, every client uses a web browser. This allows a WAF to examine each client’s browser environment and verify its legitimacy. Most traditional WAFs rely on the detection of “headless browsers” to identify hostile bots within their stream of incoming traffic.
This doesn’t work for API traffic. By definition, API requests are not submitted by web browsers; they are sent by native/mobile applications, or by services/microservices, etc. Therefore, environmental detection cannot work; there’s no browser environment to detect. This eliminates a major capability of most traditional WAFs, and it hinders them from correctly identifying hostile bot activity.
Contextual traffic analysis. A traditional WAF tends to process traffic on a request-by-request basis. It will examine the header and content of each request, looking for attack signatures. For example, the WAF can recognize and block attempts at script injection. This request inspection is still useful for API security, but on its own, it is inadequate. Endpoints can be attacked in ways which this inspection will not recognize, because the individual requests can seem innocuous.
For example, data scrapers will usually appear to be legitimate users of an application, submitting requests for content that seem normal. The attack is not contained within the requests – it occurs when the requestor collects and captures the data in the responses.
Another example is an inventory denial attack on an airline API. Bots submit API requests, masquerading as travelers using the airline’s mobile application. They begin to make reservations – this immediately reduces the number of available seats on the flight. But they never actually complete the purchase process for the tickets. Eventually, the incomplete reservations expire, and the seat inventory resets; then the bots do it again, in a continual cycle. Over time, this can significantly decrease the number of ticket purchases, because actual customers are prevented from buying them.
As these examples show, there are many attacks which are based on requests that appear to be legitimate. Traditional solutions which rely on request inspection cannot defeat them. Effective API protection requires a security solution to have a much broader understanding of user activity and the overall context of requestor behavior, in order to correctly discern the user’s intent.
Sophistication. Traditional web security involves attacks that have been around for decades: cross-site scripting, DDoS, vulnerability scans, and so on. However, API abuse has only become common in the last few years. It is a more complicated challenge, and so it attracts hackers with a higher level of technical ability. Therefore, API attacks tend to be more sophisticated than the threats handled by a traditional WAF.
Agility. Traditional WAFs rely on rulesets which do not change often. Also, they can be difficult to setup and administer.
APIs can, and usually do, evolve rapidly. This is especially true for organizations which use modern development practices such as DevOps. Most traditional security solutions do not function well in this environment; they require manual configuring and tuning each time the underlying API changes. This is a complicated, time-consuming, and potentially error-prone process.
API gateways: Useful, but not the answer
API gateways are products that are (usually) deployed as reverse proxies in front of backend API servers. They abstract away the backend, increase overall system performance by reducing calls over the network, and provide a single point of contact for clients. Sometimes it is claimed that gateways can solve the problems described above. Indeed, some gateway vendors include security features in their products, such as rate limiting, client authorization, client identification, and so on. However, these do not solve the problems discussed previously.
The modern threat environment is complex and is always changing. Even dedicated WAF vendors can have difficulty in keeping their products current and effective. On today’s Internet, an API gateway with a few add-on security capabilities cannot provide comprehensive protection, especially for all the additional challenges described above that API endpoints must face.
API gateways provide many benefits, but robust security is not among them.
Achieving effective security for API endpoints
The best approach for protecting endpoints is to deploy a cloud web security solution in front of them as a reverse proxy. A comprehensive security platform can block hostile requests and scrub traffic of all kinds: not only for APIs, but also for web applications.
A good security solution can work in tandem with an API gateway, a global CDN, cloud load balancing and autoscaling, and more, leveraging all the advantages of the latest cloud technologies and products.
Not all web security solutions offer comprehensive API protection, but some do. As APIs become increasingly important, it is worth the effort to seek and implement the best security platform for your organization.
Follow Us
