By David Bisson

Malicious actors are increasingly using API vulnerabilities to conduct digital attacks. As reported by Yahoo Finance, security researchers uncovered 11 billion attempted attacks involving API vulnerabilities between January 2020 and June 2021. More than a third of those attacks consisted of SQL Injection (SQLi) attempts. This was followed by Local File Inclusion (LFI) and Cross-Site Scripting (XSS) at 3.3 billion and 1.019 billion, respectively. Interestingly, most of those are “old school” attacks that follow known patterns - today, API attacks are far more sophisticated and unique.

Consider the API Security Top 10 list for 2019 from the Open Web Application Security Project (OWASP). That list has Broken Object Level Authorization (BOLA) as the top security issue confronting APIs. BOLA is a vulnerability where an application fails to validate that a user can access only those resources to which they are explicitly given permission. As such, BOLA attacks can expose organizations’ sensitive data, including personally identifiable information.

Broken User Authentication is another vulnerability near the top of the OWASP list. It involves organizations implementing authorization mechanisms incorrectly. Subsequently, malicious actors could compromise authentication tokens or misuse implementation flaws to assume the identities of authorized users. These attackers could also compromise an application and/or use it to conduct a distributed denial-of-service (DDoS) campaign.

Web Applications Aren’t APIs

Some might think they can mitigate BOLA, Broken User Authentication, and other vulnerabilities by approaching API security as they would traditional web applications. But they’re wrong. APIs are not traditional web applications.

At issue here is the fact that it’s no longer one request to one server. Per DevOps.com, this process now involves dozens or even hundreds of requests to dozens or hundreds of microservices. Organizations therefore need to first create the ability to discover where all their API endpoints reside and maintain a dynamic inventory of the APIs and their corresponding details. Following discovery, they need to ensure proper authentication and authorization for each API call.

Not surprisingly, traditional security tools can’t succeed in this regard. As reported by Help Net Security, 91% of organizations choose to run traditional application security tools in log or monitoring mode or turn them off entirely. Part of the reason is that some of those solutions often block valid business traffic and thereby disrupt organizations’ business processes. Simultaneously, many traditional tools produce false positives that waste resources and detract attention away from legitimate security issues.

Using legacy application security tools to protect APIs is an ineffective approach. Steve Ragan, a security researcher at Akamai, said as much to Help Net Security in October 2021.

“API attacks are both underdetected and underreported when detected,” he explained. “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, but that doesn’t mean they should be ignored.”

Indeed, ignoring APIs is the last thing organizations want to do. Gartner predicted that API attacks will become the most frequent attack vector this year. If they wish to defend their web applications against data breaches, organizations need to take their API security seriously.

Where This Leaves Organizations in Terms of Securing Their APIs

Organizations need their traditional security tools, of course, but they should not overestimate the applicability of those solutions to protecting APIs. They provide valuable security functions, but their utility goes only so far.

Salt Security agrees with this assessment.

“Use traditional security testing tools to verify certain elements of an API implementation such as well-known misconfigurations or vulnerabilities, but realize these tools have limitations,” the company advised. “No scanner is adept at parsing business logic, which also leaves organizations exposed to major forms of API abuse.”

Security teams need to do something more. In addition to using traditional application security tools, they need to invest in dedicated API security tooling that provides automated API discovery, identifies and stops API attackers, and provides developer insights for hardening APIs. Developers should, at the same time, make automated static analysis of API code an integral part of version control and CI/CD. They must also review their code for vulnerable dependencies that could leave them exposed to security issues. They should also consider using dynamic analysis and fuzzing to scan APIs for code that malicious actors could abuse in runtime.

But developers cannot – and should not – be expected to address API security on their own. That’s why TechBeacon recommends that organizations consider investing in API security tools. In particular, organizations need solutions that don’t use rules to block known attacks. APIs are unique, and therefore API attacks are unique, so organizations need AI/ML and behavior analysis engines to detect API attacks as they continue to evolve in sophistication.

About the Author: 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.