As APIs proliferate and make up the most common communication channel for internet traffic, securing them becomes more important — and challenging — to enterprise security teams. The ubiquity of APIs massively expands organizations’ attack surfaces, and it also makes them more interconnected.

In other words: APIs represent a huge security threat to all organizations.

Peter Klimek, director of technology at Imperva, likens this new world of API security to the earlier days of cloud security. “People didn’t care about cloud security until cloud migration became the No. 1 thing that everyone was really focused on as an organization,” he said. “And the number of APIs that are being developed for different use cases has really exploded.”

While organizations previously used APIs more sparingly, predominantly for mobile apps or some B2B traffic, “now pretty much everything is powered by an API,” Klimek said. “So of course, all of these new APIs introduce a lot of security risks, and that’s why a lot of CISOs are now paying attention.”

Imperva, which Gartner named a “leader” in its web application and API protection (WAAP) Magic Quadrant, lumps API security risks into two categories, according to Klimek. The first one, technical vulnerabilities, includes a bunch of risks that can also exist in standard web applications such as the OWASP Top 10 application security risks and CVE vulnerabilities. The recent Log4j vulnerability falls into this bucket — and demonstrates how far-reaching these types of security flaws can be.

Most Imperva customers tackle these API threats first, “because they tend to be some of the most acute and they require just adopting their existing application security strategies,” such as code scanning during the development process and deploying web application firewalls or runtime application self-protection technology, Klimek explained. “They tend to adopt those strategies and move it more toward the API security side. So that’s half of the equation.”

The second risk bucket, however, is more unique to APIs. “APIs are becoming a little bit different than their older sibling web applications,” Klimek said. “That’s because API security is fundamentally a data security problem.”

APIs enable people or systems to quickly query and access data or modify and mutate data, he explained. “So a lot of the parallels that we see now in API security come from some of the strategies that we have around data security,” Klimek said. “Organizations are looking at understanding who is accessing that data, where is my sensitive data, and which APIs are exposing sensitive data, and then using that as their model for how they’re approaching problems.”

There are four steps to approaching API security, according to Klimek. The first, as with most security strategies, is discovery. This includes building an API, and an API endpoint, inventory.

“And then, more importantly, as you get into that more granular level, what type of data does each one actually process? What this does is it allows the business to better understand their risk profile and the risk profile across all their API endpoints,” Klimek said.

The second step involves monitoring APIs. What does the API’s structure look like? What API requests are coming into corporate systems, and who is accessing these? Organizations need to monitor their API traffic, and then look for potentially malicious activity, according to Klimek.

“Then we get into the protection category, and generally classify protection two different ways,” Klimek said. First: what threats must be blocked in real time? “These are the types of attacks where one carefully crafted malicious request can effectively ruin your entire company,” he said, using Log4j as an example. “Those are things that we say they have to be mitigated in real time.”

The second piece involves protection against attackers playing a longer game. Instead of protecting against an attack coming in from an individual API request, this requires looking at a longer chain of events. “It requires you to understand and basically profile how data and APIs are being accessed by individual consumers or clients over long periods of time,” Klimek said. “What we’ve seen here is that the technology that’s used for this is more akin to the type of technology that you use in battling bots.”

This is because with bots and distributed denial of service (DDoS) attacks, the problem isn’t an individual request but rather a continual scraping of websites or a flood of traffic from compromised devices.

And finally, the fourth step in API security moves into verification and compliance, Klimek said. “This is where organizations start setting guardrails around what they want to see for their developer teams doing,” he explained, adding it involves shifting security left in the development lifecycle. “In this case, it’s more proactively testing the APIs earlier in the cycle to proactively identify any issues.”