Radware Survey Reveals API Security Weaknesses
A survey published today suggests there is a disconnect between the perceived and actual level of security being applied to application programming interfaces (APIs).
The survey polled 203 IT professionals in Europe, Asia and North America from organizations with more than 1,000 employees and was conducted by Enterprise Management Associates (EMA) on behalf of Radware, a provider of tools for protecting APIs. The results revealed that a full 97% of respondents are using APIs, with 92% reporting that use of these APIs has recently increased somewhat (52%) or significantly (40%).
A full 93% also reported they have a plan in place to protect those APIs, with 40% reporting their current efforts are adequate. A total of 70% claimed they have visibility into applications that are processing sensitive data. However, 62% also admitted a third or more of APIs are undocumented.
In terms of detecting an API attack, respondents said they relied on alerts from an API gateway (29%), extended detection and response (XDR) platform (29%) or web application firewalls (21%). The issue is that legacy security platforms are not likely to detect a wide range of APIs attacks, noted Prakash Sinha, senior director and technology evangelist for application security and delivery for Radware. In fact, nearly half of respondents (49%) acknowledged they view their existing tools as only somewhat or minimally effective at protecting their APIs, with 7% reporting that the solutions they have in place did not identify any attacks at all.
Sinha said that it’s clear there are a lot of APIs that are not being managed, much less secured. This has become a significant issue because most modern applications are based on microservices that rely on APIs to integrate software components at scale. The challenge is that nearly 74% of respondents said they believed container-based deployments and microservices architectures are more secure than monolithic architectures and deployments by default.
In reality, many of these applications are just as insecure as monolithic applications, because the APIs used to create them are often insecure, noted Sinha. At the same time, cybercriminals also much more adept at discovering and exploiting API vulnerabilities, he added.
Arguably, one of the biggest challenges when it comes to API security is simply determining who is responsible for it. Ultimately, cybersecurity leaders will be held accountable for any breach but, in many cases, APIs are created by developers without cybersecurity teams ever knowing they exist until there is an actual incident. More troubling still, developers often abandon APIs without removing them. These so-called “zombie APIs” are then exploited by cybercriminals to exfiltrate data without generating a cybersecurity alert.
Theoretically, the adoption of DevSecOps best practices should lead to improvements in API security as development teams assume more responsibility for application security. However, as long as humans are involved in building applications, mistakes will be made. As such, the amount of attention cybersecurity teams should be paying to API security needs to increase—especially as the sheer number of them invoked across the extended enterprise continues to grow.
