Platform Features
By Need
By Industry
Partner Program
Our Partners
Key Alliances
Resource Center
{ "term_id": 183, "name": "Chris Heggem", "slug": "chris-heggem", "term_group": 0, "term_taxonomy_id": 183, "taxonomy": "wpx-authors", "description": "", "parent": 0, "count": 5, "filter": "raw" }
Even though many enterprises are now focusing on API security, there are still significant API security gaps. Dark Reading’s 2021 Secure Applications Survey highlights that 41% of respondents treat APIs the same as Web applications, and only 23% of respondents have a dedicated process for evaluating API security.
The lack of API security maturity is why it isn’t surprising that API leaks and exploits make headlines on a frequent and consistent basis. In addition to industry maturation, there are several common misconceptions and misunderstandings that are keeping enterprises from holistically protecting their API environments. Let’s explore 5 of the most common reasons enterprises fail at closing API security gaps.
API security is making headlines with journalists, analysts, and security vendors all jumping into the fray. However, in context, “API security” is almost exclusively positioned in the media as API attack prevention. Yes, API cyber-attacks are very real. And we’ve all seen Gartner’s prediction:
“Gartner predicts that by 2022, application programming interface (API) attacks will become the most-frequent attack vector…”
APIs are so critical to the business today that design errors and simple misconfigurations can put sensitive information and company reputations at risk, which was the case with Experian and Peloton. Additionally, these honest mistakes can easily be exploited by bad actors exposing even a deeper layer of risk to the company than a standalone attack. Instead of an attacker breaking through a locked door, they may be able to simply walk through an open doorway.
A broader definition and understanding of API security is required.
API security refers to protecting the integrity of your digital environment from API vulnerabilities, API misconfigurations, and API cyber-attacks.
It’s not about protecting your APIs from an attack; it’s about protecting your digital environment and your data from all the risks associated with APIs. As simple as this shift in mindset may seem, it has significant implications to security strategies, processes, and tooling.
The nature of APIs is to connect and to communicate. Applications, services, and databases are connected by a sprawling mesh of APIs. If an API is compromised, it’s often difficult to even identify what other APIs, data, and systems could have been exposed or exploited.
The rate of new API deployments exceeds an enterprise’s ability to keep up with API testing and security. Each day the API attack surface grows, and new misconfigurations find their way into production environments. As hyperbolic as this sounds, it is the reality for enterprise organizations. Without a rapid change in their API security strategy, it is only a matter of time before more enterprises fall victim to API security vulnerabilities and attacks.
“How many APIs do you have?” is a question that most enterprises can’t answer. And if they do answer with a specific number, it’s likely wrong.
Most enterprise business units use APIs. Many teams develop APIs. Other teams are in charge of managing the deployment of APIs. And security is either a shared responsibility or given to yet another team to sort out. The end result is a lot of APIs slipping through the cracks. Enterprises do NOT have a complete inventory of APIs, and it isn’t uncommon for 30% of APIs to be unknown or unmanaged.
And of the known and managed APIs, there is often limited visibility into the communication and behavior of the APIs. “Which APIs are private and which are public?” “Which APIs are communicating sensitive information like credit card numbers and social security numbers?” Many enterprises have an intent for their API management, but validating the API behavior is still a difficult and time-consuming process.
Most enterprises have invested in WAFs (web application firewall) and API gateways to secure their web applications and manage their APIs and API assets; however, these tools alone are insufficient at achieving API security.
As stated in Dark Reading’s application security survey cited at the beginning of this article, 41% of enterprises try to secure APIs in the same manner they secure web applications. WAFs, for example, are designed to address the Top 10 Web Application Security Risks in the OWASP Top Ten. OWASP, in 2019 released the API Security Top Ten, which has very little overlap with the original OWASP Top Ten. Additionally, WAFs and gateways do not have D.A.R.T. (Discover, Analyze, Remediate, Test) API Security Strategy functionality.
WAFs and API gateways are necessary components of an enterprise’s tech stack but need to be paired with modern API security solutions to identify API misconfigurations and prevent API cyber-attacks.
With so many teams playing a role in the creation, consumption, and management of APIs, there is often confusion about which teams are responsible for API security. Is it the development team that writes the code for the APIs that is responsible for security? Is it the platform team that deploys and manages APIs across gateways and clouds that is responsible for security? Or is the CISO and their team responsible for enterprise API security?
Each enterprise has a different structure and/or a way of sharing responsibility; however, it can be loosely defined and poorly understood. Without a clear ownership structure of API security, API security vulnerabilities will continue to slip through the cracks and more effort will be placed into finger-pointing than eliminating API risks.
There are a number of new API security solutions that can be used to help overcome the challenges listed above. Give extra consideration to API security solutions that:
Experience the speed, scale, and security that only Noname can provide. You’ll never look at APIs the same way again.
Certified for your security needs.
