APIs and Security: What’s a Security Officer to Do?
APIs are powering the digital transformation initiatives underway at companies everywhere. Such is the demand from board rooms for an improved digital experience that vendors have seen an explosion in the rise of API traffic across their platforms over the past few years. Google’s API platform service Apigee recently noted a 46% rise in API traffic to 2.2 trillion calls.
Unfortunately, this increase in API consumption has mirrored the growth in attacks on API infrastructures. For example, well-known brands including LinkedIn, Peloton and Facebook, among others, suffered data breaches due to attacks on their APIs. This trend is set to continue; Gartner estimated that API abuses will move from infrequent to the most-frequent attack vector by next year, resulting in an increased risk of data breaches for enterprise web applications.
Why API Security Issues Arise
Three key patterns explain why API security issues are so frequent:
Application development is changing: It’s been some time since applications were built using home-grown libraries in a monolithic way. In those scenarios, a server-side layer controlled the logic, protected all the data and determined what could and could not be exposed to the client. With API-based architectures, applications are composed by orchestrating hundreds of internal and external services. The controlling logic mostly happens on the client-side and is totally bypassed if APIs are invoked directly.
Development teams are more agile than ever: Developers have access to rich development frameworks across many languages, powerful IDEs and many open source and commercial tools at their disposal to increase productivity. We went from releasing applications every six months to releasing several times per day. On the other hand, application security teams are still primarily dependent on manual processes to test APIs.
Security is considered too late: Development teams are, first and foremost, focused on delivering functionality. In most companies, security is not a primary objective; rather, it’s a mandatory (often dreaded!) bottleneck in the development process. Checking for security vulnerabilities is sometimes considered tedious, with analysis tools raising hundreds of false positives for devs to comb through.
These three issues make for an explosive combination: Increased APIs delivered at a frantic pace and coupled with manual processes driven by AppSec teams that are largely outnumbered by developers.
Protecting Data, Not Perimeters
Every time an enterprise exposes an API, they are effectively “punching a hole” in their corporate perimeter to expose the data.
This means that the focus of application security must shift from protecting the perimeter of the organization to protecting the data wherever it is stored and accessed. Traditional application security solutions, such as web application firewalls (WAFs) typically deployed at the edge, are no longer optimal to protect modern architectures.
Blocking API Attacks: It’s All About Context
Tools need contextual information to decide to block API traffic. For example, a scenario where several typical attacks on APIs involve using improper verbs (i.e. call GET /tokens instead of POST /tokens) or manipulating the data itself (e.g. injecting data via mass assignment or leaking data). To a WAF, those calls are just valid HTTP calls. The WAF has no context to decide that POST is good but GET isn’t, or that /tokens are valid whereas /admin/tokens are not.
Context can be static or dynamic (for example, built based on traffic), but in any case, tools need context to make appropriate decisions. The context defines the valid individual calls, the required security settings, the authorization rules, the valid workflow of calls and the data flowing through the API. The context information can equally be used at testing or execution time.
Without context, tools need to resort to a negative security model and, since they don’t have information about the traffic, your only solution is to describe what you think is unacceptable via rules and patterns. As new exploits arise, new rules need to be written.
Building Context at Design Time
Fortunately, with APIs, we can describe the API contract with de-facto standards like OpenAPI or AsyncAPI. Even better, we can do this before writing any code, at design time.
The API contract becomes a critical part of the context required to test API security but is also critical for protecting the API at runtime. It enables a positive security model approach which has long been a goal in security. If you know what the traffic must be, you can deny access to everything but the expected traffic and there is no need to manually build rules to catch bad traffic or leverage technologies like machine learning to guess what the traffic should be.
A machine-readable description of the API also enables automation at every step of the API lifecycle, including automated analysis of contracts, automated functional testing, automated data validation, and improved automated security testing. This means application security teams can focus on complex pen-testing scenarios and scale them to the development teams’ agility levels.
Prepare to Protect, Prepare to Win
We have seen how security practitioners are attempting to leverage existing technologies that are traditionally deployed to protect applications and adapt them to protect APIs. Unfortunately, they are grounded in a negative security model and with each new API representing a potentially unique attack path into a company’s systems, these solutions won’t scale to address the challenge.
A new generation of API security solutions has emerged designed to address both a positive and negative security model approach to protecting APIs. Security officers, as part of their decision-making process, need to decide what their end goal is. Is it one of embedding security into the API life cycle from design through to production? Or is it implementing patches at runtime to address known issues? Or a mixture of both? What is certain is that with an ever-increasing API attack surface, the security practitioner needs to carefully consider their API security needs and ensure that the solution(s) selected align with the strategy for the security posture they plan to adopt for today and tomorrow.
