The 2020s are making a name for themselves as the decade of API attacks. In February 2021, for example, Dark Reading covered a report in which 91% of organizations revealed that they had suffered an API security-related issue during the previous year. More than half (54%) of those respondents said that the problem had stemmed from a vulnerability discovery, while 46% noted that they had encountered authentication challenges. Five months later, security researchers published a study documenting a 348% increase in API attack traffic over the course of H1 2021. This growth eclipsed the 141% increase in overall API traffic during that period, reported BetaNews.
What’s Driving These API Security Incidents?
Simply put, a lack of focus around API security in general is to blame. Organizations are too often concerned more about bringing applications to market than they are with ensuring they’re secure beforehand. Indeed, just 39% of respondents to the survey covered by BetaNews said that they had more than a basic security strategy for their APIs. More than a quarter of participants went on to disclose that they didn’t have any API security strategy whatsoever.
To their credit, some organizations are using traditional network security solutions to try to strengthen the security of their APIs. But those tools are ill-equipped to provide visibility over a wide attack surface. As a result, many common API issues go unnoticed.
Steve Ragan, a security researcher for Akamai, agrees with this assessment.
“API attacks are both underdetected and underreported when detected,” he said, as quoted by Help Net Security. “While DDoS attacks and ransomware are both major issues, attacks on APIs don’t receive the same level of attention, in large part because criminals use APIs in ways that lack the splash of a well executed ransomware attack….”
Acknowledging this reality, it’s not surprising for Gartner to predict that API attacks will become the top attack vector over the course of 2022.
Defending Against API Attacks
If they want to avoid a data breach and other costly security incidents, organizations need to act now to block API attacks. They must consider several elements along the way. Let’s discuss three of these factors.
Shifting Left Isn’t Enough
As noted by Forbes, a shift-left approach involves shifting the responsibility for securing an application “left” in the development process. This practice entails focusing on identifying security issues before software deploys in production vs. afterward. Such an approach enables organizations to find and remove security bugs before they make it into production and potentially expose customers to digital threats such as data loss.
Sometimes shifting left is easier said than done, however. Salt Security noted that organizations often struggle with securing the build pipeline, a crucial component within shift left. Specifically, they need to ensure that they obtain “full” coverage of their build pipelines by deploying multiple types of security testing tools such as schema validators, fuzzers, and vulnerability scanners. No one security strategy is the same, however, as organizations vary in their levels of awareness, security budgets, and risk tolerance. In addition, security teams would be wise to integrate and automate their security tools into the pipeline. Doing so will help to ensure that security is built into the CI/CD processes, not an afterthought to them, thereby minimizing the amount of time that security professionals need to commit to manual tasks.
Runtime Security is the Priority in API Security
There’s no doubt about it. Runtime security is essential to blocking API attacks, as that’s when security teams can direct their focus to identifying potential security issues, detecting attacks early on, and preventing data breaches. As such, runtime protection should be at the top of the list for most organizations’ API security programs.
“If you do nothing else, focus on runtime protection as a way to ‘stop the bleeding,’ slow down attackers, and buy time for application and API teams,” wrote Salt Security on its blog.
That said, organizations also need to make sure that they eliminate underlying vulnerabilities found during runtime. They can do so by creating feedback loops for continuous improvement with their security and engineering teams. Teams can use those loops to gain insight into and remediate vulnerabilities on an ongoing basis, thereby improving their employer’s security posture over time and reducing the likelihood of a future security incident.
API Security Warrants a Balanced Approach
In support of their API security, organizations need to take an approach that balances culture with technology. A crucial element of the former is fostering collaboration between security and development. Per another article by Dark Reading, doing so will help to align the priorities of those who are responsible for writing the APIs with those who are responsible for protecting the data and other services to which those APIs connect. Organizations can complement this collaboration with ongoing security awareness training not only for their developers but also for CISOs and the security organization at large on the vulnerabilities posed by APIs, noted DZone.
As for having the right tooling, organizations need to specifically look to security tools that can minimize the incidence of shadow (unknown) and zombie (outdated) APIs. Along with full discovery, you need to identify which APIs expose sensitive data, apply runtime protections, and create that DevOps feedback loop. Organizations will also need automated tools instead of manual processes for each of these aspects of API security – humans simply can’t keep up.
David Bisson is an information security writer and security junkie. He's a contributing editor to IBM's Security Intelligence and Tripwire's The State of Security Blog, and he's a contributing writer for Bora. He also regularly produces written content for Zix and a number of other companies in the digital security space.
The opinions expressed in this post belong to the individual contributors and do not necessarily reflect the views of Information Security Buzz.