API Security Weekly: Issue 164

This week, we have news on the Log4Shell vulnerability affecting applications and infrastructure using the ubiquitous Log4j library. In addition, there's an article on how API sprawl is becoming a threat to the digital economy, a guide on API security design best practices, and views on the benefits of the zero trust approach for API security.

Vulnerability: Log4Shell Vulnerability Poses a Critical Threat to Applications

The major news this week is the critical vulnerability in the ubiquitous Log4j Java logging library. A combination of factors — including the ease of exploit (several example exploits were posted within hours of disclosure), the prevalence of the library, and the impact of the vulnerability (including complete server takeover) — has led to the vulnerability being classified a maximum score of ten on the CVSS scale. The vulnerability has been assigned the identifier CVE-2021-44228.

The affected versions of Log4j are 2.0-beta9 up to and including 2.14.1. A new version 2.15.0 that addresses the issue has been released and is expected to appear on downstream servers within days. If it is not possible to upgrade the library version immediately, remediation is possible through system properties or remove the affected class from the package library. The Veracode remediation guidance provides full details on remediation and mitigation for this vulnerability, as well as advice on identifying affected applications by using software composition analysis (SCA) techniques.

Article: API Sprawl Becoming a Threat to The Digital Economy

F5 has written an article “Continual API Sprawl: Challenges and Opportunities in an API Driven Economy”. The article investigates the sprawl of APIs and the potential impact this has on the digital economy which is so heavily dependent on them.

F5 suggests that many estimates of the growth of APIs tend to be conservative — according to F5's aggressive calculations, we will be approaching 1.7 billion active APIs by 2030. This high growth will inevitably lead to sprawl, resulting in APIs that may not be designed, tested, or managed adequately, and that are deployed in many dispersed environments. This will clearly pose a challenge to those responsible for securing such APIs.

The article cites several factors driving this sprawl:

• Sheer growth: As APIs continue to grow, it will become increasingly challenging to manage and govern them.
• Lack of standards: A lack of common standards frequently leads to duplication of effort in creating APIs and difficulties in integration between them.
• New development approaches: The adoption of microservices is further accelerating the growth of APIs, in this case, internal APIs in the so-called east-west direction.
• Continuous software development: The ability to easily deploy an API can lead to duplication of API instances, leading to maintenance challenges.
• Various computing evolutions: The drive toward a cloud operating model has led to APIs being deployed in highly divergent regions leading again to maintenance challenges.

This sprawl is posing various challenges. For instance, operating or managing APIs do not necessarily scale well, making it difficult to discover or document APIs. The ubiquitous use of the OpenAPI Specification (OAS) is seen as a natural counter to this challenge. Secondly, the rapid evolution of APIs can lead to challenges in API integration, manifesting in broken client applications. This can be addressed by using a rigorous approach towards API versioning.

From a security perspective, the challenges of API sprawl are the most concerning — in 2020 alone, 91% of enterprises experienced an API security incident. The sprawl in APIs will lead development teams to take shortcuts in how they develop APIs, including anti-patterns like re-using authentication and authorization tokens and keys, and poor server-side API implementations.

Some useful mitigation tactics against the sprawl include, for example:

• Treat the API as a product.
• Improve developer experience.
• Use spec-driven development.
• Ensure that API documentation and code libraries are up to date.
• Use consistent endpoint naming.
• Set clear guidelines for API versioning and deprecation.
• Go beyond API keys with OAuth and OpenID Connect.

Article: API Security Design Best Practices

For readers with a focus on the implementation of the API backend, we have a thorough article by Yuri Kopylovski on various considerations related to security best practices.

The guide covers topics like, for example:

• API traffic flow.
• Timeouts.
• Error handling.
• Logging strategies.
• Platform-specific considerations.

It concludes with some anti-patterns specific to session management and API gateway implementations to watch out for in terms of API security.

Article: The Benefits of Zero Trust for API Security

We have previously featured perspectives on zero trust in respect of API security, and this week we have David Bisson’s views on the benefits of zero trust for API security.

The key takeaways from the perspective of API security include the following:

• Infosec teams can leverage zero trust to scale their API governance, ensuring a balance between compliance and enabling new API development.
• Assuming that traditional network boundaries have been eliminated and not relying on network perimeters as a security control is crucial.
• The key principle is to deny everything by default and authenticate every resource.

You can subscribe to this newsletter at APIsecurity.io.