The way we need to protect APIs has changed. APIs have become the critical enablers for today’s digital economy. APIs have not only transformed how we build modern day applications and services, but have also transformed how we live. APIs enable you to pay for your morning coffee using a digital wallet. APIs allow you to make instant payments and purchases straight from your mobile phone. APIs make it possible for you to check your banking account balances, order food delivery, or schedule transportation from any location and at any time. Name any online application – they all need APIs to function.
APIs aren’t new; however, although APIs have been around for a long time, their growth has skyrocketed over the past few years. Cloud computing, advanced devops processes, and other modern technologies have made it easier and faster for developers to build and deploy APIs, and the COVID pandemic has hastened their adoption for digital services.
In the past, it used to take days to write an API. Today – due to serverless functions, microservices, containerization, Kubernetes, and other advancements – APIs can be written and exposed within minutes. Given the exponential growth of APIs and the huge volumes of API calls, protecting APIs has become challenging.
Attackers have recognized the wealth of valuable data that APIs transport and the opportunity they present. As attackers have jumped on the API bandwagon, API threats have also changed, contributing further to the risks and demanding a new approach to protect APIs.
Protecting today’s APIs requires that organizations:
- Maintain an accurate inventory
- Understand the new attack paradigm
- Become educated about top API vulnerabilities
- Implement runtime protection
Maintain an accurate inventory
Organizations must have a complete inventory of the active APIs within their infrastructure before they can even start to ensure API protection. “Shadow” or unknown APIs, and “zombie” or outdated APIs, represent an ongoing security risk for organizations. In fact, organizations have named outdated APIs as their biggest API security concern for the last four editions of the Salt Security Salt Labs State of API Security report.
However, gaining a complete inventory is not as simple as it sounds. API discovery contains many layers and can be highly complex. For example, while organizations may be aware of an API, there could be one change – a single vulnerability – that a developer accidentally included, such as accidentally exposing a token in a response, that can make that API an unknown risk. That is why API discovery should do more than just let you know that an API exists. API discovery should expose this type of vulnerability, tell you how an API is being used, and inform you about the data it ingests and exposes.
In addition, establishing your API inventory is not a one and done endeavor. Your inventory needs to be continuously and automatically updated to manage your risk and exposure. Ongoing API discovery is essential to protect your APIs, particularly given the fast pace of API updates. According to Salt Labs research, 31% of organizations update their APIs weekly and 11% update APIs daily!
Understand the new attack paradigm
As the number of APIs has increased, the threats themselves have changed. This new attack paradigm has arisen because APIs have been built upon business logic and underlying application logic. The most significant API security risks stem from business logic flaws.
Transaction-based attacks – such as a typical SQL infection – comprised the majority of past security attacks. Traditional front line, proxy-based security solutions, like a WAF, work well at stopping these types of attacks; WAFs look for known patterns and act as a firewall, blocking the known bad. However, server- or VM-based API security approaches simply don’t have a broad enough data set over time to identify today’s sophisticated API attacks.
In application logic attacks, hackers poke and prod – over and over again – to uncover holes in coded business logic. They’re seeking areas for potential exploitation, such as gaining unauthorized access to data or functionality within the API, or weaknesses in the API to launch pin-point, low-traffic, application denial-of-service (DoS) attacks.
Because of this, attacks rarely stem from a single API call. Attackers make multiple API calls as part of their reconnaissance efforts. While traditional security solutions can defend against known vulnerabilities, they cannot discover these logic-based API vulnerabilities. They lack the needed business function and logic.
To protect APIs, organizations must be able to spot logic-based vulnerabilities in APIs. This requires business function and business logic context. Security teams must see the API’s endpoints in action and understand the functional purpose of each of the endpoints. They also need to understand the behavioral characteristics of each parameter and element in use by those endpoints. A single API endpoint alone can have thousands of possible permutations of business and underlying application logic that need to be vetted and exercised in order to understand if the endpoint is capable of performing any negative behaviors.
Become educated about top API security vulnerabilities
To help businesses understand and mitigate unique API vulnerabilities and the growing threats against them, OWASP published the OWASP API Security Top 10. Despite the immense value to be uncovered in this list, findings show only 55% of organizations currently use it as part of their security program, making it an underutilized resource.
If you want a good starting point to learn about the common weaknesses and security flaws that can exist within APIs, there is no better place to start than with this list. The OWASP API Security Top 10 list includes detailed descriptions and example attack scenarios for threats.
Of the 10, the most common are: BOLA (broken object level authorization); broken user authentication; excessive data exposure; and security misconfiguration. It is also worth noting that the majority of the OWASP API Security Top 10 vulnerabilities derive from business logic flaws. Below is a brief overview of the four top API security vulnerabilities:
Broken object level authorization is the most common API threat, accounting for about 40% of all API attacks. The scary thing about a BOLA vulnerability is that many times the attacker does not have to do much to take advantage. Manipulating a singleID parameter within a header or body of an API request is sometimes all it takes.
- Broken User Authentication
Broken user authentication vulnerabilities allow attackers to use credential stuffing techniques with known or stolen authentication tokens or credentials, and brute-force attacks to gain unauthorized access to applications. Attackers can take over user accounts, gain unauthorized access to another user’s data, and make unauthorized transactions. In some cases APIs containing sensitive data are published with no authentication or authorization gates in place at all, giving an attacker free, unchallenged access to sensitive data.
- Excessive Data Exposure
When generic APIs provide more data than is needed, an attacker can exploit an application by using redundant data to extract sensitive data. APIs often send more information than is needed in an API response and leave it up to the client application to filter the data and render a view for the user.
- Security Misconfiguration
A wide range of security misconfigurations exist that often negatively impact API security as a whole and can inadvertently introduce vulnerabilities. Security misconfigurations can include insecure default configurations, incomplete configurations, misconfigured HTTP headers or HTTP headers with detailed system information, verbose error messages, open cloud storage, and more.
Adopt Runtime Protection
Last, but not least, to protect APIs, you need to constantly monitor them. Organizations must see APIs being ‘exercised’ or used in runtime to spot logic flaws. As APIs are not just straight code, you can’t simply search for flaws in development and testing. By seeing APIs in runtime, you learn ‘normal’ API behaviors within your API ecosystem, providing a baseline of ‘normal’ activity.
Understanding what is typical behavior allows organizations to more quickly identify anomalous behaviors and spot potential threats. As mentioned previously, attackers do a lot of reconnaissance to look for logic flaws, and these threat patterns usually manifest themselves as ‘abnormal’ API behaviors. Many of the business logic vulnerabilities that may lay beneath the surface of an API cannot be detected and flushed out in automated pre-production testing. .
In addition, while shift-left practices, such as improving secure coding practices through developer education and incorporating API specific testing in the CI/CD pipeline, can help improve new APIs being developed, production APIs can’t wait. Companies already have dozens or hundreds of APIs running within their environments. To reduce risks, organizations must start protecting these APIs immediately.
To develop more secure APIs, security teams also should communicate what they’re learning from API runtime findings back into developer training. Sharing API vulnerabilities that have been uncovered helps the development team to resolve them and harden future APIs.
Protecting APIs requires a holistic strategy
By their nature, APIs expose application logic. Hackers do lots of experimentation to try to identify gaps in that business logic that they can exploit. The reconnaissance needed to propagate attacks like these take a lot of time. A single API attack can take hours, days, or even weeks to unfold.
To protect APIs, organizations must analyze large amounts of API traffic and API activity over time. Spotting abuse patterns and attack patterns requires continuous deep contextual monitoring of millions of API calls and users. Large-scale data analysis, in near real time, educates teams on typical API activity and reveals the anomalies that don’t align – this is the kind of context teams need to spot API attacks and vulnerabilities before a breach occurs. Only cloud-scale big data combined with AI and ML can collect, store, and quickly analyze thousands of structural and behavioral attributes across millions of users and API calls and correlate them in near real-time to accurately discern user intent. Cloud-scale big data provides the breadth and depth of context that organizations need to protect their APIs.
*** This is a Security Bloggers Network syndicated blog from Salt Security blog authored by Nick Rago. Read the original post at: https://salt.security/blog/how-to-protect-apis