Three API security risks in the wake of the Facebook breach

Facebook recently pledged to improve its security following a lawsuit that resulted from a 2018 data breach. The breach, which was left open for more than 20 months, resulted in the theft of 30 million authentication tokens and almost as much personally identifiable information. A “View As” feature that enabled developers to render user pages also let attackers obtain the user’s access token.

The theft of access token represents a major API security risk moving forward, but also highlights how API risks can remain undetected for so long. Of course, Facebook is not unique in this risk. As Microsoft CEO Satya Nadella quipped, “all companies are software companies.”

Digital transformation and cloud migration trends have accelerated an agile development cycle known as continuous integration and continuous deployment/delivery (CI/CD), which enables DevOps to constantly push new updates–like that Facebook app in your pocket.

Yet even as the industry embraces this new software model, much of the security has been commodified by infrastructure providers like Amazon and Microsoft, including container protection, authorization, and data encryption. Likewise, the security functionality of first generation gateways and firewalls, such as DDoS protection and bot mitigation has also been consumed into infrastructure.

However, as this first generation of infrastructure is more or less as good as it gets, it suggests a deeper risk to the underlying application transportation layer, its APIs. The reason that APIs are so powerful as a communication tool is the same reason that they are so vulnerable, APIs have great flexibility in their parameters. As such, they exist in everything from so called “single-page” web applications to mobile apps, and even industrial IoT systems.

Traditionally, API traffic has moved from internal to external callers (“north-south”), which is why the first generation of security has been a tolerable band-aid. However, modern application architectures are now enabling internal application-to-application communication (“east-west”), which represents a critical risk surface because of its ability to move laterally. Furthermore, there is little visibility into this traffic.

API risk is rooted in a lack of visibility, not only into its traffic, but also into its flexible and powerful parameters, known as API specifications—or “specs.” DevOps and SecOps attempt to mitigate this risk by creating and maintaining API catalogs, which are a collection of its specs. But, the reality is that this is a highly manual process in a constantly changing environment. Keeping it up-to-date is easier said than done.

OWASP has introduced its API Security Top 10 to help make sense of this new API risk surface, which is a helpful starting point for a discussion of API risk. We can further simplify API risk into three common categories categories:

1. Unknown or outdated API specifications.
2. Uninspected APIs.
3. Uncontrolled third-party APIs.

Risks related to unknown or outdated API specifications include a complete absence of an API spec, a loosely-defined API spec, or an out-of-spec API call, which typically result from rapid development changes. Bad actors can exploit out-of-spec API calls by accessing customer data through undocumented “shadow” APIs or even simply elevating permissions through a parameter like “administration=yes.”

The risks related to uninspected APIs include launching lateral attacks through compromised servers, encrypted traffic remaining uninspected and API parameters set out of critical range—such as sabotaging an industrial IoT device by setting its temperature high enough to break down. Perhaps the most common of these risks is to miss validating the login session against its parameter. These sorts of mismatches can be the source of severe data breaches, as back-end services are unable to validate the credentials exfiltrating data.

Finally, the risks related to uncontrolled third-party APIs demonstrate that the use of APIs is not limited to incoming calls from enterprise users and partners, but also outgoing calls from business applications to external services. These outgoing calls can be abused to exfiltrate data, such as exposed storage server APIs. Alternatively, public API calls may use compromised credentials to access enterprise services to exfiltrate data. Unlike private data centers, it may not be possible to turn off these public APIs.

No matter how you slice it, the source of these API risks is a lack of visibility, both into their traffic and into their parameters. Next-generation API security solutions offer the promise of automatically discovering and continuously maintaining API catalogs, for further monitoring and alerting. For those that do maintain an up-to-date API catalog, there is benefit not only to security, but also to improving quality assurance and debugging across the DevOps process.

As DevOps moves from development to test environments, and ultimately into production, an API catalog can be used to compare and contrast areas of improvement. In this regard, it is imperative not only for CISOs to gain visibility into their APIs, but also for CIOs. In this way, they will not only secure their APIs, but also accelerate their digital transformation.