It used to be that practicing data security meant securing individual machines and the networks they resided on (firewall, anyone?). But as applications have risen out of specific machines and into the cloud, so have security threats. Instead of the vulnerabilities existing solely at the network layer, they are now also at the broad API layer, the doorway into our modern, cloud-native applications. APIs specify the types of interactions that are allowed with our applications and the level of security needed to interact. They are, therefore, the veritable keepers of the keys to the kingdom of data stored in the cloud, or accessible from the cloud.

The use of APIs is on the rise, and so too is the number of API security breaches. As APIs continue to grow, a recent Gartner report predicts that “by 2025, less than 50% of enterprise APIs will be managed.” This means that less than half of all APIs that potentially have access to important data in applications will be known, secured and controlled. Given both the explosive growth in APIs and in API security breaches, there is much work to be done. If all APIs allowed by an application aren’t known and secured, a huge attack surface is just waiting to be exploited and breached.

Why do breaches happen? Some of the top motivations include:

• Stealing Personally Identifiable Information (PII) and selling it on the dark web
• Ransom or extortion
• Espionage, either political or corporate
• Leaked data

The attack vector for wide-scale data breaches can take many forms. For some types of exploits, even the most solid API implementations wouldn’t prevent them, such as where a human is “attacked” via social engineering, phishing, MFA fatigue or where someone internal to the company is the bad actor. However, there are many examples where API security is the source of vulnerability, including:

• Common Vulnerabilities and Exposures (CVEs)
• Denial of service (DDoS) attacks
• Data injection attacks
• Security misconfigurations
• Lack of encryption, which enables data exposure via "sniffing" attacks
• Insufficient function-level authentication (i.e. Broken Function Level Authorization, or BFLAs)
• Insufficient object-level authentication (i.e. Broken Object Level Authorization, or BOLAs)
• Unrestricted 3rd party API access
• Undocumented “backdoor” APIs (i.e. shadow APIs)
• Old, deprecated APIs (i.e. zombie APIs)

Any of these types of vulnerabilities can weaken an application’s API security posture.

You don’t have to look far to find reports of API security breaches. A DarkReading article estimates that US companies have lost anywhere from $12 billion - $23 billion in 2022 alone from API data breaches. TechWire Asia puts the estimate as high as $75 billion globally. That’s already a lot of zeros without even considering the damage to companies' reputation and trust.

APIs are here to stay, and are increasingly becoming a common target for data breaches, so without further ado, here is a list of the top 5 data breaches in 2022 that were due to API security issues, ordered by number of accounts impacted:

1. 1.8 million accounts exposed In January 2022, an insurance company reported a breach of 1.8 million user accounts. The vulnerability was in a web service application that inadvertently allowed access to protected parts of the application. This can be categorized as a BFLA exploit.
2. 3.7 million accounts exposed In January 2022, a digital scheduling platform had a security breach that exposed the PII for 3.7 million user accounts. The vulnerability was an unsecured AWS S3 bucket which contained the customer database. This was a BOLA exploit and is an example of how 3rd-party APIs (in this case S3 APIs) allowed access to private data.
3. 5.4 million accounts exposed In July 2022, a major social media platform reported an API breach that occurred from late 2021 into 2022 and exposed the PII of 5.4 million user accounts (the actual number of accounts may be significantly higher). The vulnerability was with an API that allowed users to find other users, and mistakenly revealed PII. Some of this data was sold on the dark web, and some was allegedly released for free. The underlying issue here was unsecured data, thus this was a BOLA exploit.
4. 7 million accounts exposed In February 2022, a major breach was revealed for an online marketing platform,exposing PII for 7 million customer accounts. The culprit here was, again, an unsecured, unencrypted S3 bucket containing PII.
5. 10 million accounts exposed In September 2022, an international telco company reported a breach in 10 million accounts, with an ensuing $1 million extortion demand from the attacker. The vulnerability was an unsecured public API (BFLA).

The sheer scope of the exploits listed above underlines just how much data can be compromised when an API is breached, and it's not just external, public-facing APIs that can create risk. Internal APIs can be just as problematic – or even more so – because they can access data that typically wouldn't be exposed publicly. It's critical to secure all assets that are accessible via APIs, even internal ones that aren’t expected to be exposed in the public domain.

Given the many ways in which APIs can be hacked, there's no "trick" for protecting all of them, but there are effective layers of security that can be built into API architectures and API gateway security tools to provide a multi-pronged strategy of protection. It is becoming increasingly important to follow API best practices, starting from design, development, testing and staging and continuing into production.

A recent Forbes article provides a list of guidelines to mitigate API security issues, including taking inventory of existing APIs, doing a security assessment of each and providing threat protection both during development and in the field.

One method of assessing API security is the CVSS Vulnerability Scoring System, which can help identify any APIs that present a potential security risk and rate how severe the risk is. This allows an application team to prioritize security risks and create a mitigation plan.

In terms of API discovery and observability, the Forbes article recommends using APIClarity, which is an open-source solution that has the ability to:

• Learn and reconstruct OpenAPI specifications for APIs already in production
• Detect shadow APIs that could inadvertently allow access to protected data
• Detect zombie APIs that should no longer be allowed access to data
• Detect BFLAs before they become a problem
• Use fuzzing technology to feed bad data into API requests in order to harden API security and prevent data injection
• Integrate with top API gateway technology
• Integrate with OpenTelemetry technology in order to record API flows

And for a commercial-grade solution, Panoptica provides many of the features of APIClarity, and much more. We live in a cloud-first world, however that doesn’t mean we can’t have visibility and a solid security posture for our APIs to help mitigate the risk of being yet another data breach headline. Stay tuned for an upcoming blog detailing the features of APIClarity.

---

Anne McCormick is a cloud architect and open-source advocate in Cisco’s Emerging Technology & Incubation organization.