Who’s responsible for the security of your development and production environments?
Oftentimes, it’s not the security team alone, but the developers themselves. This trend is unlikely to change in the coming years as many security teams simply can’t keep up with the scale and pace of DevOps.
APIs, the connective tissue that ties DevOps together, is increasingly vulnerable and under attack by cybercriminals. By 2024, it’s predicted that API abuses and related data breaches will nearly double in volume.
While APIs will play a vital role in the future of cloud native architecture, the potential risk they pose today and in the future is significant. In fact, the number of new API vulnerabilities grew in 2020, with sensitive data exposure ranking as the most common vulnerability.
For developers being asked to be the cybersecurity defenders for their organization, they must pay close attention to three malicious breeds of API attacks.
1. Shadow API
How many APIs does your organization have? Research by Aite Group indicates that most organizations don’t know. For those that have an API inventory, the average number was 620 per organization.
Now, how many APIs don’t you know about? The issue of shadow APIs is not new, but it will become a greater source of risk in the coming years.
In fast-paced DevOps environments, the creation of shadow APIs can happen easily. When APIs are published without security review or controls, they become invisible to the security team and API gateway. Other times, it’s the result of an API published outside of a defined process or after the API structure changes with the update of an application. In some cases, the developer may not be fully aware of a publication process and assume they have autonomy to publish the API into production.
There’s also the issue of human error. If a developer applies the Backends For Frontends (BFF) pattern in their application design, it may result in backend services — usually meant to be accessed only by internal services — exposed to direct pass-through access from external, client API calls.
The issue with shadow APIs is that they have access to the same sensitive information that published, secured APIs do, but no one knows where they exist or what they’re connected to. This can create a compliance violation and regulatory fine, or worse, a probing attacker can use it to access your organization’s data.
2. Automated bot attacks
The issue of automated bot traffic is not the burden of any one specific industry — it’s a prevalent issue that will impact every business that has a website, mobile app or public-facing API. Web applications are a rich target for a botnet operation because they are a direct path to the sensitive data which can be scraped and shared or sold on the Dark Web.
These types of attacks are harder to stop because the bots mimic legitimate human behavior and can evade detection. Unlike other types of attacks, botnets operate around the clock and are purposefully designed to carry on repetitive tasks that are harder for humans to maintain. When breached, APIs can result in the loss of personally identifiable information, data leakage and more.
Many organizations fail to manage the security of their APIs by relying on simple authentication tokens or basic IP rate-limiting. Unlike the authentication of human users through multi-factor authentication, API tokens are often a single factor authenticating an API call.
For a developer that doesn’t have formal information security training, this is a tricky threat to stop.
3. Deprecated or zombie API
The deprecation of APIs is part of the natural API lifecycle. However, when the API has not been properly disabled, it becomes a dormant breeding ground for cybercriminal activity – usually outside of the purview of developer and security operations.
These unmonitored APIs are analogous to an unlocked window. Motivated criminals can sneak in to access data or execute more sophisticated attacks — often without the developer or security team ever knowing. This is the underlying risk factor that becomes a software supply chain attack.
Deprecated APIs are often left unaddressed because they are overlooked and not included as part of a regular software update. Thus, the API can be exploited for account takeover, fraudulent transactions, or data extraction.
Look for an advanced solution to stop an advancing problem
While a majority of organizations use an API gateway solution today, this technology is not a silver bullet for growing API security risks. Gateways are great for delivery and access management, but lack the sophistication to stop complex attacks.
Further, approaches like gRPC, MQTT and GraphQL are growing in popularity as businesses demand more diverse engineering models. However, this will open the business to more sophisticated attacks on APIs. Adopting a baseline of governance standards and security tools is essential when API protocols with structures even more flexible than RESTful APIs are adopted.
While the DevSecOps movement is an important industry effort, this mentality alone cannot stop business logic attacks – the concentrated abuse of rules that dictate how an application operates. The challenge is that runtime protection policies that protect business logic cannot be easily shifted left. Instead, organizations should seek out security tools that not only provide runtime protection, but also seamlessly embed into the application development process.
Developers and security operations can start addressing today’s top API attack risks by first having a clear assessment of such risks. The assessment starts with automated discovery and keeping an API catalog up-to-date. As attacks are becoming more complex, the solution should combine bot detection that can identify good bot from bad bot, and a bot from a legitimate human user. Lastly, to address the issue of deprecated APIs, a solution also needs to monitor the lifecycle of API tokens along with versions of APIs.
Together, this approach will enable developers to adequately address API security risks without slowing down their innovation agenda.
