The transition to APIs has created threat actors’ new favorite playground and security teams’ biggest headache. This is partly due to the acceleration of software development and organizations’ desire to release software faster; in this environment, it’s more likely that security assessments and reviews are bypassed in this accelerated “shift left” model, said Harold Byun, vice president of products and marketing at Baffle in an email comment. “While exposed APIs increase the number of methods that an attacker can use to access systems and data, organizations should look for ways to more tightly integrate security into the development and deployment process,” Byun said. But to integrate security into development, organizations need to know where the greatest risks lie.
How APIs Create Security Risks
The proliferation of APIs that power applications, microservices, containers and serverless functions have created one of the greatest sources of security risk that businesses face today. The reason is simple: It’s not the development team’s responsibility to handle security. At the same time, however, security operations teams don’t have visibility into APIs. Because you can’t protect what you can’t see, Lebin Cheng, head of API security, office of the CTO at Imperva, pointed out three primary ways APIs create security risk for organizations:
- A legacy application, initially deployed for internal use, is exposed externally using gateways that perform only fundamental authentication and authorization, with inadequate protection against sophisticated data exfiltration attempts. Because APIs are often connected directly to a data source, this can give attackers direct access to sensitive data.
- Modern applications are increasingly built with outsourced components and/or services. This means that the majority of the application stack isn’t actually owned by the enterprise. What connects all these components is the API, but organizations often lack the visibility to monitor these API calls or the ability to secure the APIs in runtime.
- The speed of software development is the Achilles’ heel of a security team. Developers need to move quickly and publish lines of code and APIs. However, the traditional approach of penetration testing for vulnerabilities isn’t feasible in today’s modern application workflow because it takes too long to conduct. This is creating a tug-of-war internally between the DevOps and SecOps teams.
“Data exfiltration through a compromised or vulnerable API is the risk organizations need to be most worried about,” said Cheng in an email interview. According to research by Imperva Research Labs, the number of new API vulnerabilities grew at the same time other vulnerabilities decreased; by 2024, it’s predicted that API abuses and related data breaches will nearly double in volume.
Enter the Hackers
API traffic makes up nearly three-quarters of web traffic, presenting a tempting target that hackers are eager to exploit. In fact, Gartner estimates 90% of cyberattacks could be API-related by the end of 2021. There is a growing trend toward the “backends for frontends” (BFF) pattern where internal applications and services are made available to external users through an API gateway to support today’s self-service customer and partner model. This is incredibly problematic as it offers external users access to internal systems. This gives threat actors an opportunity to look for misconfigured or non-configured gateways and allows them to abuse the backend to harvest data.
Shadow APIs are another growing security threat. When an API is published or updated without a security review or adequate controls, Cheng explained, it becomes invisible to the security team and to the API gateway. Shadow APIs can even hide inside a well-defined open endpoint and expose an unknown vulnerability in the application, giving hackers access and the opportunity to crawl through the network.
“Organizations need to also be worried about the preponderance of software supply chain attacks, as many of these incidents involve compromised APIs,” Cheng added. For example, the SUPERNOVA vulnerability that devastated SolarWinds involved an authentication bypass that permitted hackers to remotely execute malicious code by leveraging a vulnerable API as the command channel.
“This very public incident was particularly worrisome because the criminals weaponized the software’s APIs to communicate with their command-and-control server—without anyone knowing,” said Cheng.
Addressing API Security Challenges
When it comes to protecting APIs, organizations need a solution that gives them full visibility into API behavior, monitors for anomalies and still supports the API gateway. The SecOps team needs continuous visibility to watch for suspicious activity so they can react immediately to any nefarious behavior. As it relates specifically to APIs, Cheng said, organizations should strive for:
- Full visibility and an always-up-to-date inventory of APIs and their data exchange patterns.
- Automated profiling of application API behavior, preferably early in the development and testing stages. Special attention should be paid to data exchange patterns so that runtime protection can be enabled based on an always-up-to-date baseline of behavior.
- Runtime protection that does not depend on rigid rules but is instead predicated on automated, self-adaptive anomaly detection.
- A feedback loop that helps developers address vulnerabilities efficiently through enhanced API design and security testing.
“In some ways, the security risk presented by APIs is self-inflicted; a derivative of the collective innovation and digital transformation the world economy is pursuing,” said Cheng. The time has come to make security a higher priority in the API development process.