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.
About the Author
Related Blog Posts
The everywhere attack surface: EDR in the network is no longer optional
All endpoints can become an attacker’s entry point. That’s why your network needs true endpoint detection and response (EDR), delivered by F5 and CrowdStrike.
F5 NGINX Gateway Fabric is a certified solution for Red Hat OpenShift
F5 collaborates with Red Hat to deliver a solution that combines the high-performance app delivery of F5 NGINX with Red Hat OpenShift’s enterprise Kubernetes capabilities.
F5 accelerates and secures AI inference at scale with NVIDIA Cloud Partner reference architecture
F5’s inclusion within the NVIDIA Cloud Partner (NCP) reference architecture enables secure, high-performance AI infrastructure that scales efficiently to support advanced AI workloads.
F5 Silverline Mitigates Record-Breaking DDoS Attacks
Malicious attacks are increasing in scale and complexity, threatening to overwhelm and breach the internal resources of businesses globally. Often, these attacks combine high-volume traffic with stealthy, low-and-slow, application-targeted attack techniques, powered by either automated botnets or human-driven tools.
Volterra and the Power of the Distributed Cloud (Video)
How can organizations fully harness the power of multi-cloud and edge computing? VPs Mark Weiner and James Feger join the DevCentral team for a video discussion on how F5 and Volterra can help.
Phishing Attacks Soar 220% During COVID-19 Peak as Cybercriminal Opportunism Intensifies
David Warburton, author of the F5 Labs 2020 Phishing and Fraud Report, describes how fraudsters are adapting to the pandemic and maps out the trends ahead in this video, with summary comments.