The rapid proliferation of Application Programming Interfaces (APIs) is spearheading digital transformation, leading to explosive growth in adoption of APIs in recent years. In fact, it’s hard to think of any software that doesn’t use or is in itself, an API. By supporting swift development and deployment, they help developers quickly and efficiently bring applications together while providing a better user experience across web and mobile applications. However, if not properly protected, APIs can be detrimental to an organization.
Not only do APIs expand the attack surface by providing more points of entry for attackers, but they are also more susceptible to business logic abuse and fraud, making them an ideal target for automated attacks. Such attacks are increasing at an alarming rate. As reported in our 2023 Bad Bot Report, 17% of all the attacks that targeted APIs in 2022 were from bots that sought to abuse business logic, and 21% were other types of automated threats. It should come as no surprise that a lack of protection from automated threats is a contender for the new 2023 version of API vulnerabilities from OWASP. But why are APIs an increasingly targeted vector?
APIs are everywhere
APIs are an essential part of modern software development. According to MuleSoft, 98% of organizations now use public and/or private APIs. A survey commissioned by Imperva found that the minimum average number of APIs an organization manages today is no less than 300. What’s more, a recent report found that 70% of developers expect to increase API usage this year. As the volume of APIs grow, the attack surface broadens. So, it should be expected that we will see APIs become a prime target for bad actors in the coming years.
Organizations lack visibility
A lack of visibility can be attributed to the following causes:
- A lack of visibility into all existing APIs and their functionality
- A lack of visibility into the proportion of API traffic that comes from bots
Organizations need to identify and document all of their APIs. Many APIs exist and are exposed publicly, but the organization has not inventoried, or actively known about them. These are commonly referred to as shadow APIs. Examples include: old API endpoints that were deprecated but never removed, new API endpoints that weren’t inventoried or documented, or when a developer inadvertently makes a change that exposes non-public API endpoints to the internet. Imperva Threat Research found that 14% of all API traffic goes to shadow APIs. This begs the question: How can you protect what you don’t know is there?
There is also the challenge of distinguishing between human and bot traffic, let alone between good and bad bots. The problem is rooted in the fact that everything looks like a bot to an API, as they are designed for automated clients. This makes it tricky for organizations to protect their APIs against bot attacks. These APIs handle large volumes of requests but lack built-in defense mechanisms. This makes it difficult to detect and block malicious bot traffic, enabling attackers to use automation without the risk of raising any alarms.
But, there are more effective ways to segment an API’s intended consumer in order to prevent bots from accessing them. In particular, many APIs are designed to supply data to mobile and single-page browser apps. By identifying the target consumer of the API, the security team can restrict unauthorized clients from abusing the API.
APIs provide direct access to sensitive data
APIs serve as a direct pathway with access to sensitive data, business functionalities, resources, and other sensitive information. A recent analysis of API endpoints from Imperva found that 13% of APIs handle highly sensitive information, such as credit card numbers, social security numbers, home addresses, etc. If an attacker gains access to an API that handles sensitive data, they could potentially access all of the data the API is designed to handle, resulting in a data breach.
APIs are inherently easier to target
APIs are machine readable by nature, making it easier for developers to parse and for attackers to exploit. Put simply, because of the way APIs handle requests, attackers can use automated tools (e.g. bots) more easily, without the need to emulate browsers. APIs are similar to SQL interfaces – they simplify querying data, yet expose their logic publicly.
Another nuance about APIs is that they are typically stateless, as opposed to most traditional web apps that are stateful. Generally speaking, stateless applications are considered to be more at risk than stateful applications because they don’t keep track of the user’s session information. In a stateless application, each request is treated as an independent transaction, and the application does not maintain any information about previous requests from the same user.
Combining the relative simplicity of targeting APIs with the ease of orchestrating an attack through bots-for-hire/bots-as-a-service makes for a dangerous combination of an easy target and a low-cost, low-effort attack.
Business logic is often overlooked
According to Postman, 44% of API developers have less than 2 years of experience developing APIs. Additionally, 48% of API developers conceive, implement, test, and deliver an API to production within one week. When it comes to securing their APIs, developers commonly apply a standard set of rulesets, often neglecting the business logic side and thus exposing APIs to business logic vulnerabilities. Even if an API has proper authentication and authorization mechanisms, implementation flaws can still provide opportunities for attackers to exploit the API. These are vulnerabilities that can be exploited by using bots to wreak havoc.
For example, a search API can be scraped by bad bots to collect data, or a login API can be attacked to gain illegal access to user accounts. In the specific case of the login functionality, APIs rely on using a token as a form of authentication. Thus, it requires no need for parsing. Instead, these tokens and other forms of authentication can be intercepted or stolen by attackers and then used to gain unauthorized access to the API and the associated account or data.
Even if developers attempt to mitigate bot traffic, they often use traditional security tools and techniques. These include the likes of rate limiting, signature-based detection, blocking protocols, etc. Such techniques are often ineffective against today’s highly sophisticated bot attacks that target APIs.
It’s not just about the business logic
Scraping and Account Takeover are two examples of bot attacks that can exploit an API’s business logic. There are a variety of other ways in which bots can target APIs. One such example is distributed denial of service (DDoS) attacks. Bots can be used to launch DDoS attacks against APIs, overwhelming them with traffic and making them unavailable to legitimate users. DDoS attacks are particularly challenging for GraphQL-based APIs because the user has far more flexibility about what data they query and the complexity of those queries, which can often result in unoptimized requests to the backend database.
Bots can also be used to probe APIs for vulnerabilities, such as SQL injection or cross-site scripting. This isn’t a direct attack, but rather a reconnaissance phase that aids attackers in identifying potential vulnerabilities that they can later exploit. These are just a few examples of how bots can harm APIs.
Many business logic-level vulnerabilities are specific to an implementation flaw of an API. For example, a typical excessive data exposure vulnerability (categorized as one of OWASP API Security Top 10) allows bad bots to exfiltrate data by calling APIs that return excessive amounts of data more than what is required for the function. Bad actors were seen leveraging bots for reconnaissance to discover this kind of business logic vulnerability.
To conclude, organizations are becoming increasingly reliant on APIs, leading to rapid growth in adoption and usage. In turn, the attack surface that these organizations must be able to protect today has significantly grown. With bots getting more sophisticated by the day, and the ease at which they can target APIs’ business logic, they pose a significant risk that we predict will only grow.
Imperva protects APIs from bot attacks and online fraud
The Imperva Cloud Application Security platform is built from the ground up with our best-of-breed solutions, like Advanced Bot Protection and API Security. They work together to provide the ideal platform for securing your online business. This defense-in-depth solution is a one-stop shop for protecting your organization’s most valuable assets from today’s ever-shifting, highly sophisticated threats.
Imperva Advanced Bot Protection protects websites, mobile apps, and APIs from today’s most sophisticated bot attacks without affecting legitimate users. It prevents bot operators, attackers, unsavory competitors, and fraudsters from abusing, misusing, and attacking your applications. It embraces a holistic approach, combining the vigilant service, superior technology, and industry expertise needed to enable customers with full visibility and control over human, good bot, and bad bot traffic.
Imperva API Security provides continuous protection of all APIs using deep discovery and classification of sensitive data to detect all public, private, and shadow APIs to empower security teams to implement a positive security model. Through machine learning and automation, Imperva API Security continuously detects and classifies changes to determine ‘threat and risk’, enabling security teams to keep up with DevOps.
Try Imperva for Free
Protect your business for 30 days on Imperva.
