APIs are at the core of today’s digital innovation initiatives and have become the number one attack vector for applications. Find out what API security is, why it is so important, and what you can do to protect your APIs against modern threats.
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.
As the number of APIs continues to grow and with organizations around the world relying on them more and more to deliver their critical business initiatives, they have become a prime target for attackers. Our State of API Security Report Q1 2023 shows that unique attackers have grown by 400% within a six-month period. And yet, 30% of respondents still have no API security strategy in place.
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 — of which there are many.
Read on to learn why API security has become a critical concern for today’s organizations and how it’s different to application security.
Learn why APIs present unique risks and best practices for securing them
Download nowAPIs have become a primary attack vector for cybercriminals, with bad actors realizing how lucrative it is to target the APIs that connect today’s digital services and sensitive data. In fact, according to the State of API Security Report Q1 2023, 94% of companies experienced API security problems in production APIs within the past year. In 2017, analyst firm Gartner predicted that by 2022 APIs would become the primary attack vector for cybercriminals and they have certainly been proven right. With API attacks making headlines around the world in recent years, Gartner has included API security in its security reference architecture in 2022, recognizing the need for dedicated API security tools and methods.
By 2022, API abuses will move from an infrequent to the most-frequent attack vector, resulting in data breaches for enterprise web applications.”
20 November 2017
“Predicts 2018: Infrastructure Protection”
—Strategic Planning Assumption
As 2022 approaches, this prediction could arguably be counted as ‘missed’ — but only because we underestimated the steep rise in attacks on APIs.”
6 December 2021
“Predicts 2022: APIs Demand Improved Security and Management”
The critical importance of API security is also becoming increasingly obvious for senior officials in today’s organizations. In fact, almost half (48%) of our State of API Security survey respondents indicated that API security has now become a C-level discussion. This finding is also supported by the results of a global survey conducted by independent research company Global Surveyz on behalf of Salt Security, where the majority (78%) of CISOs globally said that API security is a higher priority today than it was two years ago, and 95% said that API security will a top priority over the next two years.
Although traditional security measures, such as API gateways and Web Application Firewalls (WAFs) can add value to an organization’s security stack, they cannot keep up with today’s increasingly sophisticated API attack methods. In fact, they’re not keeping attackers from stealing sensitive data, affecting the user experience, or causing other damage. To prevent and mitigate API attacks, you need a security strategy and technology that is purpose-built for APIs.
Bad actors targeting APIs have moved beyond traditional “one-and-done” attacks such as SQLi and XSS. Their focus now is on finding vulnerabilities in the business logic of APIs. Your APIs are unique, so the attacks have to be as well. It takes attackers days, weeks, or even months to probe and learn your APIs, and they use “low-and-slow” techniques that stay under the radar of traditional security tools.
One and done
Single API call – seconds to minutes
Known attacks – SQLi, XSS, etc.
Low and slow
Sequence of API calls – days to weeks
Business logic attacks – requires context
REST API security, SOAP security, and GraphQL security all play an important role in ensuring the protection of APIs and web applications. Each of these technologies has a different approach to security which requires specific security considerations.
REST stands for Representational State Transfer and is an architectural style commonly used in web services. It relies on standard HTTP methods such as GET, POST, PUT, DELETE and uses URLs to identify resources. REST APIs bring their unique set of security considerations, such as:
To protect REST APIs effectively, all these aspects must be taken into account, in addition to other REST API security best practices.
SOAP (Simple Object Access Protocol) is a protocol used to exchange information in web services. It generally uses XML and relies on other web protocols such as HTTP, SMTP and TCP. There are also some important security considerations for SOAP:
GraphQL is a query language for APIs and a runtime for executing those queries with a backend system. Unlike REST, which exposes multiple API endpoints for different resources, GraphQL uses a single endpoint for all queries. Here are some of the most important security considerations for GraphQL:
Ultimately, the security of any API, whether REST, SOAP, or GraphQL, depends on a combination of best practices that cover authentication and authorization mechanisms, data validation, and the use of secure communication protocols. A robust API security strategy that covers discovery, runtime protection and shift-left practices is essential to keep APIs protected against emerging threats.
The first step to being able to effectively protect APIs is understanding why today’s attacks are different. Today’s most common API attacks can be split into four categories:
In this type of attack, the attackers take advantage of APIs that are either completely unknown to an organization — shadow or zombie APIs — or APIs whose security posture is not visible, such as unmanaged or third-party APIs.
To execute this type of attack, a bad actor will use an API exactly as designed but leverage the results in an unintended and malicious manner by exploiting design or development flaws that allow for malicious outcomes, such as data exfiltration.
In a business logic-based attack, hackers will use reconnaissance techniques over time to poke for vulnerabilities in each API’s unique business logic. During the reconnaissance phase, which can last days, weeks or even months, attackers seek areas to explore, such as gaining unauthorized access to data or functionality within the API.
This type of threat manifests when a bad actor uses social engineering techniques to access privileged API keys. This allows them to steal credentials and use the API as if they were a legitimate, authenticated user or admin. According to the State of API Security Report Q1 2023, in the last year, 78% of attacks came from seemingly legitimate users who have maliciously achieved the proper authentication.
To help the API security industry gain a deeper understanding of the most common API attacks, the Open Web Application Security Project (OWASP) released its first-ever API Security Top 10 list of vulnerabilities in 2019. The list has been updated in 2023 and lists the ten more significant API vulnerabilities. Of these, the most common are:
Broken object level authorization (BOLA) represents around 40% of API attacks and is the most common API threat.
As APIs frequently expose endpoints that handle object IDs, this creates a large potential attack surface. Object level authorization is an access control method that is typically implemented at the code level to verify a user's ability to access a certain object. Modern applications use a variety of intricate and pervasive authorization and access control systems. Developers frequently neglect to apply these checks before accessing an object, even when an application includes a robust infrastructure for authorization checks. Attackers can easily exploit API endpoints that are vulnerable to broken object level authorization by manipulating the ID of an object that is sent within an API request. BOLA authorization flaws can lead to data exfiltration as well as unauthorized viewing, modification, or destruction of data. Ultimately, BOLA can lead to full account takeover (ATO).
Attackers can easily target authentication processes, especially if they are fully exposed or accessible to the public. The second most frequent vulnerability reported by OWASP is broken user authentication, which enables attackers to utilize credential stuffing, stolen authentication tokens, and brute-force attacks to obtain unauthorized access to apps. Attackers are then able to control users' accounts, gain unlawful access to other users' data, and conduct unauthorized transactions. Technological issues, such as inadequate password complexity, missing account lockout criteria, overly long rotation times for passwords and certificates, or the usage of API keys as the only authentication method, can result in faulty authentication in APIs.
Attackers who can successfully take advantage of weaknesses in authentication procedures may be able to access another user's data without authorization and carry out illicit transactions using that user's account.
Broken Object Property Level Authorization merges attacks that happen by gaining unauthorized access to sensitive information by way of Excessive Data Exposure (previously listed as number 3 in the 2019 OWASP API Security Top 10) or Mass Assignment (previously in sixth place in the 2019 list). Both techniques are based on API endpoint manipulation to gain access to sensitive data.
The main reason for introducing this new threat on the list is that, even if an API can enforce sufficient object-level authorization security measures, this might still not be enough to protect it. More specific authorization that covers the objects and their characteristics is often required. The varying access levels within an API object must also be considered, as an API object often has both a public property and a private one.
The Unrestricted Resource Consumption vulnerability has replaced the previous number 4 in the OWASP API Security Top 10, Lack of Resources and Rate Limiting. However, while the name changed, this vulnerability remains the same overall.
Resources, like the network, CPU, memory, and storage, are used up by API calls. The user's input and the endpoint's business logic have a significant impact on the number of resources needed to fulfill a request. The size or quantity of resources that a client or user may request may not necessarily be constrained by APIs. This not only has the potential to negatively affect API server performance and cause Denial of Service (DoS), but it also makes APIs that support authentication and data retrieval vulnerable to brute-force and enumeration assaults, including token and credential cracking.
According to the State of API Security Report Q1 2023, only 54% of respondents prioritize the OWASP API Security Top 10 as part of their security programs, even though 62% of attempted attacks against organizations leverage at least one of those methods.
Traditional security solutions including WAFs, 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:
With APIs constantly being developed and changed by today’s DevOps teams, the types of threats faced by APIs have also changed. In the past, transaction-based attacks, such as SQL injection and other code execution methods, were the most prevalent tactics, but today’s attacks often aim to exploit the underlying application and business logic behind each API. With 37% of companies updating their APIs once a week, it’s not realistic to expect development teams to spot every possible API vulnerability before deploying a new or updated API.
Traditional attacks, like SQL injections or cross-site scripting, still happen, but today’s most successful, application logic-based API attacks don’t follow those kinds of “one-and-done” mechanisms that leverage known vulnerabilities. Because every API endpoint is different and each attack rarely stems from a single API call, every API attack is essentially a zero-day attack, with traditional tools being unable to detect them via their rule-based and signature approaches. Bad actors are taking their time with their reconnaissance activities. They may take weeks or even months to look for data, poking for flaws and inducing abnormal behavior to find subtle ways to disrupt the supply chain or exfiltrate data from an API.
Historically, organizations have relied on testing to spot security flaws before deploying an application. However, the widespread adoption of agile development methodologies and the issue of API sprawl have made testing for every single API vulnerability simply impossible. While standard pre-production testing can find some gaps in API security best practices, they won’t uncover vulnerabilities rooted in API business logic gaps — which are precisely the flaws that today’s attackers will aim to exploit. Additionally, it is not realistic to expect any developer to write fully secure code every time, so the only way to detect and stop API threats is to have runtime protection in place.
Explore the changing nature of API attacks and protect your organization
Download nowAPIs 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 best protection for APIs is a dedicated platform built from the ground up with API security in mind. The right API security platform should automatically:
A complete API security solution should be able to collect, store, and analyze hundreds of attributes across millions of users and API calls and, more importantly, leverage artificial intelligence (AI) and machine learning (ML) to correlate them over time. Gaining this breadth of context will require cloud-scale big data, as server or virtual machine-based approaches won’t have a broad enough data set over time to identify today’s sophisticated, low and slow API attacks. Only with this kind of adaptive intelligence and deep context will you have what you need to protect all your APIs.
To learn more about how Salt can help defend your organization from API risks, you can connect with a rep or schedule a personalized demo.
