API Security Weekly: Issue 166

This week, we have a comprehensive article on approaches to securing large API ecosystems, an interesting read on how to create OpenAPI definitions from HTTP traffic, how “Frankenstein APIs” are exposing businesses to additional risk, and why the continued API proliferation presents security challenges to organizations.

Securing Large API Ecosystems

First up this week is an excellent article from Michał Trojanowski in TheNewStack discussing the challenges facing the security of large API ecosystems. Trojanowski’s view is that security patterns applied to small-scale API deployments do not scale nor are they appropriate for larger-scale API deployments.

APIs tend to grow in either breadth (a flat hierarchy exposing large numbers of APIs directly) or in depth (a nested hierarchy of APIs coupled together):

Both patterns present security challenges in their own right, namely:

• For breadth-grown APIs, any caller with a valid token can access any of the API endpoints — the scope of access is typically too broad to adequately secure the endpoints.
• For depth-grown APIs, tokens may be reused between layered API endpoints, leading to security issues or leaking tokens to 3rd party services.

Trojanowski suggests some possible solutions to overcoming these challenges.

1. Use a claims-based authorization scheme (for example, the audience claim aud) to limit the API access for a given token.
2. Use token-sharing approaches (tokens are exchanged between coupled API services) to limit the scope of downstream services using a token, thus also limiting the impact of lost or leaked tokens.
3. Use a dedicated entitlement management system, such as Open Policy Agent.

The key takeaway here is that large-scale API deployments are complex and fraught with danger if an overly simplified approach is taken with regard to security.

Creating OpenAPI Definitions From HTTP Traffic

Readers of this newsletter will know I often advocate for an API-design-first strategy based on the OpenAPI Specification (OAS) at its core. The benefits are well established now, including ease of documentation, easier testing and mocking during development, and of course, being able to embed security as early as possible in the design lifecycle.

The biggest challenge to the design-first approach is the fact that in many cases, organizations already have deployed a considerable number of APIs in production that do not have the corresponding OpenAPI definitions. Typically, this presents a challenge to teams to “reverse-engineer” a specification from an existing implementation.

In an article on APIsYouWon’tHate, Phil Sturgeon describes an elegant method to obtain an OpenAPI definition by reverse-engineering based on snooping the HTTP traffic to APIs. The solution uses the Akita observability tool to extract the details for the API definition from the web traffic log. Sturgeon’s approach uses the mitmproxy tool to capture traffic and then dump the traffic in HAR format. The Akita tool is then used to convert the HAR archive into an OpenAPI definition in YAML format.

As the drive toward design-first accelerates, good, robust, and automated solutions for reverse-engineering existing API deployments become increasingly important: this is a great starting point!

“Frankenstein APIs” Explained

Brenton House has written an article on his so-called “Frankenstein APIs” this week, describing them as APIs which are “creatively pieced together using unorthodox methods and is driven by a strong need for functionality.”

House describes “Frankenstein APIs” arising when an existing piece of functionality does not exist and there is a strong business need to provide a bespoke functionality. The most common anti-pattern is that development teams use a variety of non-standard methods and tooling to accomplish the business objective. Unfortunately, the resultant APIs can be notoriously fragile in terms of maintainability, extensibility, and, of course, security. Typically, developers are more focused on simply getting the job done, and delegate or totally omit security controls that might otherwise be required.

This is a quick and fun read on the topic. The key takeaway from House is to fully embrace an API-first strategy and to resist the temptation to rudimentary and fragile shortcuts.

Security Pitfalls of API Proliferation

The final article this week comes from Byron Acohido who discusses how API proliferation is leading to security pitfalls. This thought-provoking article suggests that APIs are rapidly increasing the attack surface of an organization because APIs act as a conduit between various services, each of which may be vulnerable to attacks. Essentially, the API acts as a “built-in tool on steroids”  facilitating attacks by adversaries.

Attackers are increasingly aware of the value of APIs as an attack vector, and many recent major cyber security breaches started with discovery or reconnaissance through public APIs before attackers pivoted to other internal systems. Additionally, APIs are also an invisible attack vector because they are often poorly documented or invisible to traditional protection mechanisms.

Rather unsurprisingly, Acohido’s advice for avoiding such security pitfalls is to fully embrace a shift-left approach toward API development, thereby ensuring that APIs are made visible and that any security issues can be identified and addressed as early as possible.