The challenge of securing APIs [Q&A]

Technology continues to advance at an unprecedented rate. The development and use of Application Programming Interfaces (APIs) being a particularly notable example.

The latest Salt Labs State of API Security report found that overall API traffic increased 168 percent over 12 months, with API attack traffic increasing by 117 percent in the same time period. Perhaps understandably, many CISOs are struggling to keep up.

According to the same report, 94 percent of organizations suffered an API security incident across 12 months. Included in this grouping, are household names such as Experian, Peloton, and Starbucks. Even Lego has had a close call, rectifying a potentially catastrophic API vulnerability late last year. Huge companies, with large security budgets, consistently fall foul of API security incidents. Clearly, traditional application security techniques simply aren’t up to scratch when it comes to securing APIs.

With this in mind, we spoke to Yaniv Balmas, VP of research at Salt Security to clear up some of API security's most frequently asked questions.

BN: Can zero trust architecture protect APIs?

YB: Unfortunately, many API risks can't be mitigated by zero trust. The goal of zero trust is to restrict access, whereas APIs need access to function. Most APIs are public or open, designed to be consumed by the internet as a whole and a large customer base, presenting unique challenges to zero trust.

What's more, API attacks typically occur in trusted channels and authenticated sessions. Attackers know if they can obtain an authorized user's keys or credentials, they can access valuable data. By piggybacking or hijacking authenticated sessions with stolen active session cookies, authentication tokens, two-factor authentication challenges, API keys and other authentication material, hackers aren't hindered by zero trust architecture. Keep in mind that, according to the State of API Security report, a staggering 94 percent of exploits occur against authenticated APIs.

When it comes to zero trust, organizations must go beyond the principles of authentication and authorization. They require API runtime protection to continually validate an authorized user's access and behaviors against API resources, spot the anomalies, and pinpoint the bad actors.

BN: Can cloud security offerings protect APIs?

YB: While some cloud security providers do provide tools such as API management or API gateways, point products such as these aren’t sufficient for protecting enterprises against API attacks. These tools have limited API security capabilities at both the application and API layer, leaving APIs underprotected. API attacks are effectively zero-day exploits, meaning that security tools designed to look for known 'bad' behaviors -- signatures or blacklisted IPs, for example -- will never be able to properly protect APIs. It's also worth noting here that as APIs are application logic, cloud customers hold the ultimate responsibility for protecting them within the shared responsibility model for security.

BN: Why can't IAM, WAFs or API gateways protect APIs?

YB: While IAM, WAFs and API gateways are all necessary and important tools in every organization's security stack, they fall short of protecting APIs -- largely because they don't provide the necessary visibility or security controls.

Attackers consistently bypass access controls, as well as harvesting keys and tokens. Contemporary hackers are experts at circumventing access controls, piggybacking on an authenticated user session or harvesting authentication material from traffic, device storage, or application code These attack techniques cannot be detected by IAM, API, or WAF solutions.

These tools also fail to detect API specific problems -- business logic abuse and authorization exploits, for example -- because they rely on signatures and rules for attack detection. To make matters worse, the API management components inherent with them may also be exploitable.

What's more, IAM, WAFs and API gateways all rely on proxying. As proxy models slow API communication, organizations typically fail to mediate every API in use with a gateway or WAF -- especially for inner or internal APIs. This results in a lack of visibility into how those APIs are being used.

BN: Can APIs be secured with workload protection?

YB: Workload security protections provide a lot of benefits. Among other things, they aid in providing infrastructure security to ensure you aren't running workloads on vulnerable software versions, and are also useful for blocking access to a workload to external users. However, they fall short of providing API or application-level context, thus failing to secure APIs themselves.

BN: How effective is shift-left for securing APIs?

YB: While implementing security in the development stage is a worthwhile practice, shift-left support doesn’t mean that every API will be secured pre-production. Developer testing tools simply cannot identify all vulnerabilities. Many common API security issues can't be identified as part of automated design, development, and build scans with common security analysis and testing tools -- business logic flaws cannot be spotted unless the APIs are exercised.

Photo Credit: Panchenko Vladimir/Shutterstock