The planet is awash with APIs, the mechanisms used by computers to exchange information, the building blocks of all software. Enterprises build their own APIs for internal use or to enable customers to interact with their systems. They use APIs to communicate with partners in extranets and across clouds. They use third-party APIs to access ready-made functionality – to display Google Maps or to use postcode look-up tables in forms, for example.
The number of APIs is growing exponentially as mobile, web, and cloud applications proliferate. Some industry statistics:
- The average organization uses 15,000 APIs
- API use is growing at around 200% a year
- 200 million or more APIs are already in use
- 90% of an estimated 45 million software developers use APIs in their work
- There are over 100 billion API calls to open banking applications each year, expected to grow to 580 billion by 2027
Not surprisingly, APIs are also a significant and fast-growing attack vector. According to Gartner: “The explosive growth of APIs is expanding the attack surface of organizations, giving malicious actors new breach and data-exfiltration opportunities.”
Depending on your point of view, it’s either very surprising or very unsurprising that around 50% of the APIs in use are unmanaged.
Surprising because they pose an obvious and growing risk. Unsurprising because the explosion in API use is compounded by a lack of awareness of the risks – and because APIs are hard to manage. Developers frequently publish new APIs or new versions without bothering to delete their predecessors. Cyberspace is littered with zombie APIs, exposing back-end systems and data but unmonitored and providing no business value.
An ever-expanding and poorly patrolled attack surface: this is a hacker’s dream come true.
Gartner’s warning highlights one of the obvious risks of API security – APIs are crossing points for a lot of sensitive traffic. In banking or ecommerce apps, these might include customers’ account details or credit card numbers. But APIs expose not just a company’s (and its customers’) data but also the business logic behind services. Weaknesses in business logic present hackers with new ways to launch attacks that are likely to go undetected before serious losses occur.
For example, we did some work for a bank that was using a routine to round up very small sums in currency exchange transactions. The algorithm was inconsequential for typical trades as it meant a difference of a fraction of a cent. But the system applied no limit to the number of transactions a single customer could perform in a day, and by bypassing front-end controls and attacking their business logic directly, it was possible to perform a large number of small transactions that would allow an attacker to use the rounding function to print money into our own account. We’ve gotten similar results with customers in the crypto industry, where abusing API business logic allowed us to steal cryptocurrency as well.
Of course, the bank had controls that would have alerted it to the issue eventually but acknowledged that it could have taken several million dollars worth of anomalous trades before any red flags were raised. This example illustrates a couple of important principles of API security. The most useful APIs are public. They’re meant to be used. You can’t hide them or make them too hard to access without stopping them from doing their job.
Techniques like penetration testing can help, but even penetration tests are only point-in-time exercises, and the testers only evaluate the scope provided. Companies with API blind spots don’t know how to scope the APIs in, and most penetration testers either won’t be asked to test the business logic or lack API-specific skill sets to assess what a competent API attacker could do with their access.
The second lesson is that it doesn’t make sense to focus on just one part of the API lifecycle. Shift-left principles are rightly focused on building in security at the point of design and coding, but the production lifecycle of code is just as important. Things change. The original code is tweaked by another developer. Documentation is poor or non-existent. The business is under pressure. Updates might not be thoroughly tested. And even if development and testing were impeccable and revisions are meticulous, there may be something that was missed in the original design that could come back to haunt you. Shift left, yes, but stop looking right at your peril.
You don’t limit testing an airliner to only the design phases of construction. You run a program of test flights without passengers onboard. When it’s in service, you keep running automated checks, and you continually monitor its critical systems all the time it’s in the air. We need to do something similar with APIs. The problem, as we’ve already seen, is the sheer number of them. Not all of them are carrying passengers or valuable cargo. Some of them are doing banal jobs – or no job if they’ve been retired or superseded.
As every CISO knows, the biggest challenge in security is not identifying threats but spotting the ones that matter and getting them in priority order.
How you do this is critical. First, you need to make the risks visible.
This isn’t hard if you know where to look and security teams are already waist-deep in alerts. The hard bit is ranking them in a meaningful way. Doing this requires a three-dimensional view that takes into account:
- Context: What is this API doing? What data or processes is it providing access to?
- Business impact: the potential consequences of a breach or exploit
- Likelihood: the chances of it happening
In other words, you want to know: can a bad thing happen, how bad would it be for your business if it did, and how high is the probability of the ‘badness’? Each of these factors then needs to be weighted and correlated to provide a risk score. To use a non-technical analogy, if one of your risks is a ‘savage lion,’ but the context is that the lion is in a steel cage, the score could be low. If another is a family of mice, but the context is a paper bag, you might reach a similar conclusion. If your lion is in a paper bag, well, you get the idea. Doing this requires much more granular data than most tools currently provide. The secret is to gather the information from multiple lenses. That means not looking only at, say, traffic analysis – useful though that is when an API is in production – but on analysis of the source code, which provides the context and at the scale of the attack surface, which informs probability.
This 3D, high-definition approach enables businesses to manage their API risks with certainty and accuracy, providing much-needed guidance on how to use already overallocated developer and engineering resources to focus on their highest risks first.
Let’s end with two surprising thoughts. Firstly, how wide-open APIs are to external attack. Secondly, how little the industry appears to have done to produce comprehensive solutions that address the whole problem from source code to the outside world. With API traffic accounting for 9 of 10 packets on the web today and growing, this is a problem we all need to solve right now.
