The average number of Application Programming Interfaces (APIs) a company runs now is 420. According to Akamai, more than 83% of its traffic as a CDN is API traffic. The facts can no longer be ignored, more than half of the traffic on the Internet today is now no longer human to application traffic, but application-to-application traffic. With the rise of 5G becoming a reality and more Internet of Things (IoT) devices come online, this traffic will continue to grow, not ebb. The days of single monolithic apps are also gone as they usher in a new era of micro-services sitting behind APIs and hackers know it.
"If I were to advise a hostile nation state on how to incapacitate the United States, I'd tell them to go after the APIs first." -Anonymous
It isn't just APIs at small businesses getting breached either. Unfortunate members of the breached API club also include Verizon, Samsung, Google, Facebook, Apple, T-Mobile, Marriott, the list goes on and on. So if these multi-billion dollar, large cap companies who can afford to hire floors of developers and security engineers that span their entire campus can't seem to get it right, what chance do you have, right?
I'm here to tell you that you do. You just need to recognize that APIs are the new attack surface and that your Web Application Firewall (WAF) that you're trying to secure your APIs with is like trying to remove a nail with a screwdriver. It just doesn't work.
The problem is often a discrepancy between what the API server (API provider) supports and what the contract with the API client (API consumer) allows. The problem is further compounded by developers who are leaving keys in their source code and publishing it to source code control and repository sites like Gitlab and Github, such was the case just this week with Samsung.
These sorts of problems also extend to developers of mobile apps who are hard-coding API keys, tokens, and credentials into mobile apps not realizing the apps can be decompiled using freely available tools, as was evidenced in my own research report published last month with Arxan Technologies and subsequently released at Aite Group.
The fact is, until developers stop making mistakes like hard-coding keys and tokens inside readable source code, realize that web application firewalls were not designed to interrogate API traffic, use API security gateways instead, performing API penetration testing, and leverage static code and dynamic code analysis, the situation will get worse before it gets better.
If you need a one-stop shop for API security guidance, news, and breach information along with details of those breaches, check out what the folks at 42 Crunch have created at the apisecurity.io community site.
Coming this month will be a new research report I'll be publishing on the state of the API security market, it's players, the problem and solution, and how to address it with these new breed of tools. For more information, visit my research microsite at Aite Group.
So what's your opinion? Why do you think organizations continue to get breached through their APIs? What do you think the biggest reason is behind the breaches? What questions do you have about API security?
Leave your comments in the section below!
Like & Share
As usual, if you liked this article, please support me by clicking LIKE and share it with your own feed! This is the best possible way that you can support me and my continued research. If anyone has anything to add or comment on in this article, please feel free to share it with everyone below in the comments section! Learn more about me at my homepage at www.alissaknight.com, LinkedIn, watch my VLOGs on my YouTube channel, listen to my weekly podcast episodes, or follow me on Twitter @alissaknight.