APIs are everywhere. They enable business innovation and power mission-critical operations for enterprises. With the growing dependence of businesses upon APIs, the awareness of the need to secure and protect APIs is increasing as well. A lot has already been said and written about the need for API Security:
Gartner states that “by 2023, API abuses will move from infrequent to the most frequent attack vector, resulting in data breaches for enterprise web applications, and by 2025, more than 50% of data theft will be due to unsecure APIs.”
A survey conducted by IBM across 550 organizations that have been impacted by data breaches between March 2021 and March 2022 reports an average cost of $4.35M per data breach and 83% experienced more than one breach that year. Also important to note is that breaches caused by stolen or compromised credentials had the longest lifecycle with an average of 243 days to identify the breach and another 84 days to contain it.
But how do attackers manage to find and exploit these vulnerabilities? What tactics do they apply and how do they go about it? Here is a 90-minute live API hacking demonstration that illustrates how an attacker will try and test your API to find vulnerabilities and exploit them. Make sure you grab some coffee and snacks and enjoy this blockbuster!
For those of you who can’t spend the time, I’ll share the most important lessons here:
APIs are designed for openness and manipulating data. This is why they’re valuable to businesses. But it is also why attackers like them so much. Where in the past Security through Obscurity may have worked, it will not work with APIs.
The OWASP API top 10 provides good insight into the types of vulnerabilities that attackers will try to find. In the wild, most breaches are caused by a combination of vulnerabilities, not by a single vulnerability.
Applying strong security policies consistently is difficult. The number of APIs in organizations grows at an unprecedented pace. Vulnerabilities often originate in simple mistakes, ignorance, or by cutting corners for the sake of speed. In-house development teams, outsourcing companies, and 3rd party software providers all use different technologies, and frameworks and all have varying security skills.
So what can you do to protect your APIs? Teams will make their own technology choices that match their requirements, budgets and deadlines. You need to enable teams in your organization through powerful guardrails. A strong API Security practice builds on three pillars: API Management, Shift Left and Shield Right.
Full-Lifecycle API Management should be the centerpiece of your API Security strategy. Through centralized API Governance, with an API Catalog and API Gateway, you will be able to stay in the know about what APIs exist, how they are being used, and by who. You will be able to standardize protection policies to ensure the same level of security across all of your APIs. At the same time, you are a facilitator by enabling teams to reduce the scope of what they need to worry about. But make sure that API Governance can be embedded seamlessly into their CICD processes to ensure you do not become a bottleneck to their delivery.
Empower teams to validate their security practices early on in the development lifecycle. By Shifting Left the risk of mistakes is much lower and the cost of fixing mistakes is reduced dramatically. Embrace deliberate API design as designing API contracts makes analysts and developers consciously decide what an API should and should not do. This API contract enables a range of automated validation with specialized tools within the CICD pipeline.
The API contract also helps to Shield Right, to continuously analyze and compare which APIs are available in your environments, how they are being used, and if any API consumers are showing abnormal behaviors. Should any threats be detected, the API Gateway can easily be instructed to block these.
The combination of these three pillars provides teams in your organization with powerful guardrails that allow them to make their own decisions while empowering them to apply appropriate security practices with confidence. If you want to learn more, I can recommend the following links:
I’ve also had a lot of fun taking the free, self-paced penetration testing courses by Corey Ball and Dan Barahona over at APISEC University. I’ve been working with APIs for ages and I still picked up new things!