Recipe for Disaster: API-first with Security-last Strategies
There is a growing demand for APIs. Whether helping to fuel the digital economy by enabling mobile apps or internally pumping up productivity through automation and orchestration initiatives, APIs are everywhere.
Many organizations have adopted the digital rallying cry of "API first!" To wit, a majority (60%) of respondents to Cloud Elements' State of API Integration 2018 make an API available to any developer. It's paying off. A staggering 85% of organizations are generating at least some revenue from APIs and API-related implementations. The bulk (59%) are generating between 11 and 50% of their organization's revenue. More than one in ten (11%) generates over half their revenue just from APIs. (MuleSoft's Rising value of APIs)
But let me remind you that they make their APIs open to ANY developer. Not any well-intentioned developer, but any developer.
The open nature of the API economy today is one of the reasons it's unfortunate that an API-first strategy is all too often accompanied by a security-last strategy.
A veritable cornucopia of API-related security incidents involving high-profile organizations can be found with relative ease. Whether mentioned by Forbes or uncovered by our own F5 Labs, these organizations have suffered API-related security breaches that were preventable with well-understood security practices and tooling.
Our own Ray Pompon - Principal Threat Research Evangelist for F5 Labs - noted in his research on API security:
"…you can see patterns associated with the same, classical problems in application security that we’ve always had: attackers gaining access by brute force attacks or stolen credentials. Furthermore, once authenticated to the API, attackers exploited the overly broad assigned permissions."
From <https://www.f5.com/labs/articles/threat-intelligence/reviewing-recent-api-security-incidents>
The same, classical problems. Because at the end of the day, APIs are most often implemented as HTTP-transported URIs carrying a payload of JSON or XML data. Which is not all that different from an HTTP-transported URI carrying a payload of POSTed form data.
And let us not forget that an API is just an interface to code. Code that, based on WhiteHat Application Security Statistics, has an average of 39 vulnerabilities per 100K lines of code (LOC). Wait, that's for a traditional app. How about 180 per 100K LOC if you implemented the interface (API) using a microservices architecture. Either way, that's a lot of vulnerabilities.
An API carries with it the same vulnerabilities as its counterpart, the web app. And that means it needs the same attention with respect to security as a web application.
And yet the importance placed on API security is not on par with that of web applications today - at least not based on existential evidence exposing the lackluster approach to security testing carried out. An informal poll by SmartBear found that only 12% of respondents conducted "extensive" API security testing today. Nearly twice that - 23% to be exact - conducted NO API SECURITY TESTING at all. That's in line with more formal research conducted by SmartBear that found 80% of respondents test their APIs.
Which still leaves 20% that don't.
API-first is a great way to engage in the digital economy and transform both business and operations into lean, mean digital machines. But putting security last is a great way to turn that into a trending, bitter hashtag on Twitter*. And nobody wants that.
So if you're going to go API-first - and you should - then you need to bring along security as a first class citizen. Don't accept a security-last strategy for your APIs.
Some simple steps to help you get started:
- If it exists, test it.
- If there is user input, don't trust it.
- If there is a user login, protect it against brute force and credential stuffing attacks.
- Be mindful of the need to maintain and patch the systems and services upon which your API rests. Their vulnerability is your API's vulnerability.
Stay safe out there.