Application programming interfaces (APIs) are the building blocks of modern applications. Think of them as the on-ramps to the digital world. They keep everyone connected to vital data and services, enable all sorts of critical business operations, and make digital transformation possible.
The number of APIs is growing quickly. Our recent survey shows that 26% of businesses use at least twice as many APIs now as a year ago.
All the good things about APIs are also what make them prime targets for attackers. And that’s why companies need to secure their APIs.
The Open Web Application Security Project (OWASP) defines API security as focusing on strategies and solutions to understand and mitigate the unique vulnerabilities and security risks of APIs.
The most important aspect to understand is that API security is not the same as application security. Read on to find out why.
APIs are a preferred attack vector for cyber criminals. And the attack surface continues to grow. The average number of APIs per company increased by 221% in 12 months.
As the attack surface has grown, and as more bad actors have realized how lucrative it is to target APIs, the number of API attacks has skyrocketed. That same research report shows that 95% of companies had an API security incident in the last 12 months, API attack traffic grew by 681% while overall API traffic grew 321%.
The bottom line is that existing security measures aren’t working for APIs. They’re not keeping attackers from stealing sensitive data, affecting the user experience, or causing other damage.
To stop attacks, you need a security strategy and technology purpose built for APIs.
Security solutions including web application firewalls, API gateways, API management tools, and identity and access management (IAM) tools weren’t designed to prevent attacks on APIs. That’s because securing APIs offers unique challenges:
OWASP published the API Security Top 10 to describe the ten most common API flaws. This list is a good starting point for understanding common weaknesses and security vulnerabilities in APIs. Of these, the most common are:
Broken object level authorization is the most common API threat, accounting for about 40% of all API attacks. Attackers can easily exploit API endpoints that are vulnerable to BOLA by manipulating the ID of an object sent within an API request. Because the server component typically does not fully track the client’s state, these vulnerabilities are extremely common in API-based applications. Automatic static or dynamic testing cannot easily detect BOLA authorization flaws. BOLA authorization flaws can lead to data exfiltration as well as unauthorized viewing, modification, or destruction of data. BOLA can also lead to full account takeover (ATO).
Traditional security controls, such as WAFs and API gateways, miss these types of attacks because they have no ability to understand API context and so cannot baseline normal API behavior. To prevent BOLA attacks, you must be able to spot when an authenticated user is trying to gain unauthorized access to another user’s data, for example. To prevent BOLA attacks, API security solutions need the ability to analyze large amounts of API traffic over time. This approach requires cloud-scale big data so that the system has sufficient storage capabilities to establish a rich baseline of normal activity across millions of API calls and users, over days, weeks, and even months. Only then will the system have the context needed to spot abuses such as BOLA attacks.
Broken User Authentication
Broken user authentication allows attackers to use stolen authentication tokens, credential stuffing, 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. Authentication mechanisms present an easy target for attackers, particularly if they are fully exposed or public. Technical factors that can lead to broken authentication in APIs include, among others, weak password complexity, missing account lockout thresholds, excessively long durations for password/certificate rotations, or use of API keys as the only authentication material.
Because traditional security controls lack the ability to track attack traffic over time, they cannot decipher the different forms of advanced attacks that target authentication, such as credential stuffing and credential cracking. An API security solution must be able to profile the typical authentication sequence for every API flow to detect abnormal behavior, such as missing credentials, missing authentication factors, or authentication calls that are out of sequence. To mitigate advanced attacks that target authentication, an API security solution must monitor and analyze large amounts of production API traffic, requiring cloud-scale storage as well as AI and ML.
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. Relying on client-side code to filter or obscure sensitive data causes problems, as attackers regularly bypass client-side web application and mobile application code and call APIs directly.
Traditional security scanning and runtime detection tools will sometimes alert on this type of vulnerability, but they are unable to differentiate between legitimate data returned from the API and sensitive data that should not be returned. An API security solution must be able to baseline and track API access per endpoint and per user to identify excessive consumption of sensitive data. Moreover, a solution must also provide API context and a range of response actions, so that not every transmission of sensitive data creates an alert or blocked request.
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, verbose error messages, open cloud storage, and more. Misconfigurations enable attackers to gain knowledge of the application and API components during their reconnaissance phase. Attackers can also exploit misconfigurations to pivot their attacks against APIs.
An API security solution must be able to identify misconfigurations and security gaps for a given API and its serving infrastructure. It must suggest specific remediation steps to employ when manipulation attempts are made and the application server itself is not configured to reject the request or mask sensitive data in the response. With the ability to analyze all API activity and establish a baseline of typical API activity, an API solution can help identify excessive data and sensitive data sent in error messages.
But don’t limit your concern about API security to the Top 10. Attackers use other techniques as well. They borrow techniques from application or network attacks. They combine different exploits for an attack. They’ll also automate attacks to increase their chance of success.
Most successful API attacks target gaps in business logic. For example, in the Experian incident, the hacker did lots of trial and error and ultimately determined that if he used all zeroes for birth date fields, he could pull back the credit score of any American. The developers writing the APIs had never considered that kind of manipulation and didn’t require that the fields actually conform to a valid calendar date - they merely require numerals.
APIs are challenging to protect. Traditional solutions can’t handle the complexities of the API ecosystem. Attackers know this, which is why they focus on APIs.
The following best practices can help you improve your API security posture:
The short answer is that API security is everyone’s problem. But often making it everyone’s problem means that no one is responsible for fixing it.
That’s why you need to assign people to be API security leads. You can start with your application security team — if you have one. They can often act as security champions within your DevOps teams, and developers, in turn, can teach your security teams about API constructs.
Your API security expertise will likely be scattered across your organization. You may find knowledgeable people in development, and others in infrastructure, operations, or security. Or you may find that experts are concentrated in API product teams.
Across all these API experts, choose a set of API security leads to drive cross-function collaboration across all the groups to ensure discovery, testing, protection, and incident response are all addressed in your API security strategy.
The best protection for APIs is a dedicated platform built from the ground up for API security. The right API security platform should automatically:
Look for API security that can collect, store, and analyze hundreds of attributes across millions of users and API calls and, more importantly, leverage AI and ML to correlate them over time. Gaining this breadth of context will require cloud-scale big data – server- or VM-based approaches simply won’t have a broad enough data set over time to identify today’s sophisticated API attacks. Only with this depth of context will you have what you need to protect all of your APIs — even the ones you didn’t know you had.
The unsafe consumption of APIs can lead to security breaches, exposing sensitive data, user credentials, or proprietary information, as attackers may exploit vulnerabilities in API usage to gain unauthorized access, execute arbitrary code, or perform unauthorized actions within the system.
Improper Inventory Management is the ninth security threat listed in the OWASP API Security Top 10. By exploiting this vulnerability, attackers can gain unauthorized access to sensitive data, or even gain full server access through old, unpatched or vulnerable versions of APIs.