Mark O’Neill and Dionisio Zumerle are two of the goto analysts at Gartner when it comes to API security. Recently, Mark and Dionisio teamed up on a webinar titled API Security: Protect your APIs from Attacks and Data Breaches. It was a valuable session for anyone looking for a primer on API security and in this post, I’ll cover some of the highlights and provide some perspective.

API are becoming the most frequent attack vector

The session kicks off with the well-known quote that anyone familiar with API security should be familiar with – “By 2022, API abuses will move from an infrequent to the most frequent attack vector, resulting in data breaches for enterprise web applications.”

Mark reminds us that 2022 is just around the corner, not that a switch will flip on Dec 31, 2020, but more so to remind us that API incidents have been increasing for a while. In fact, APIs are already a component of some of the largest security incidents of 2021. Do a search for “API” + Experian, Peloton, or LinkedIn, and you’ll see what I mean.

Recently Gartner updated this prediction, saying that “By 2024, API abuses and related data breaches will nearly double.” as if things in the world of API security weren’t challenging enough. At Salt, we’d have to agree with Gartner’s prediction. Our State of API Security Q1 2021 report showed that nearly all respondents (91%) had suffered a security incident in their production APIs in 2020. The bottom line is that attackers are quickly realizing the opportunity of targeting APIs, and organizations across the globe are starting to realize the risk of not securing their APIs. 

How are APIs attacked?

APIs are susceptible to many threats, and Mark and Dionisio outline the following four main ways APIs can be attacked:

1. Unsecured API keys in repositories and storage
2. Hard-coded credentials (incl. API Keys) in applications
3. API logic flaws
4. Sniffed API calls

Arguably the first two and number four on the list can and should be addressed by best practices. 

• Unsecured API keys should not be left exposed in places like cloud storage or code repos like Git. Exposure of these credentials could allow an attacker to gain unauthorized access to an API as a legitimate user or administrator.
• API keys and other credentials should not be hardcoded into applications and devices such as IoT endpoints. Similar to the point above, finding keys and credentials could allow an attacker to gain unauthorized access to an API. Dionisio goes into more details about this later in the session and provides some options to avoid this scenario. 
• Teams must ensure that attackers cannot find successful API calls in logs or by sniffing to prevent them from replaying these calls in their attacks. Attackers use several common tools such as Portswigger Burp Suite to replay API calls during their attack.

Number three on the list, API logic flaws, is not something you can easily train your development team to avoid and not something you can protect with just any application security tool. Yes, there are best practices to follow when it comes to developing an API. However, as Mark points out, “Every API is different. You have to understand the working of the API to secure it.” and understanding the granular details of an API can be a tedious task.

While developers continue to get better about security, expectations are to develop code and innovate quickly. This rapid pace of development can compromise security, meaning that API will inevitably release with potential vulnerabilities. 

Another component that adds to the complexity of securing APIs is that many applications are a combination of APIs and, therefore, a combination of logic. Often it’s not just one group that is developing the APIs for an application, but more commonly, it’s multiple groups, and those groups can be 3rd parties. Leveraging externally developed APIs creates even less visibility and control over the logic being used for the API, adding to the complexity of protecting it.

If multiple APIs and external development aren’t enough, add to that the rate of change that APIs undergo. APIs are often a key component to enabling CI/CD development practices meaning their functionality, and therefore logic is being updated regularly, which can be as frequent as every week or even every day. For security, this constant change makes APIs a moving target.

The reality is that your APIs will release with vulnerabilities, and you can’t completely depend on your developers and dev-time efforts to address API security. You need to complement development efforts with protection at runtime.

When it comes to runtime protection for APIs, Mark points out that “there is no one size fits all way to secure APIs.” This means you can’t apply the same signatures or security policies across all of your APIs and expect them to be effective. Each API needs to be understood and protected differently because their usage is unique, and their vulnerabilities are also unique.

To illustrate the risk of API logic flaws, Mark highlights the number one threat on the OWASP API Security Top 10 list – Broken Object Level Authorization (BOLA). This threat takes advantage of API logic flaws, specifically authorization flaws, to gain unauthorized access to data. BOLAs are a surprisingly common API security issue seen in most API attacks and highlighted in almost all API vulnerability disclosures.

Who is responsible for API security?

As organizations take steps to address API security, one of the first places they may look to is the development team. A poll asked the question “who has responsibility for API security” and it was no surprise to see “Application Developers” in the lead.

We saw a similar response in our State of API Security survey earlier in 2021, where 36% of respondents say developers or DevOps teams hold primary responsibility for securing APIs. It’s natural to think that developers create APIs, and if they employ security best practices and leverage tools to uncover gaps before runtime, then the problem is solved.

Referring back to the previous section, while it’s valuable to leverage developers to employ best practices and continually improve API security, depending on dev team efforts alone is a risky proposition. Our State of API Security survey showed that of the respondents, 91% said they had suffered a security incident in their production APIs, highlighting that overconfidence in development teams for security was not enough.

A more realistic approach to API security is one that balances development team security efforts with runtime protections. Both Mark and Dionisio highlight Gartner research that echoes this sentiment outlining the importance of including security teams in API strategy, how this correlates to maturity, and how it positively contributes to the security of APIs and cloud-based applications.

Consider security across the full lifecycle

An important point that Mark points out is the need to think about API security in the context of the API lifecycle. The concept of the API lifecycle is something Gartner has applied to API management, and Mark argues for using the same concept for API security. He outlines where to apply API security with four key functions:

• API Discovery (design time) – You need to know what it is that you’re securing and discovery at this stage includes knowing who is creating APIs, what APIs they’re creating, and where those APIs reside.
• API security testing (design time) – Testing at this stage allows you to uncover and resolve potential vulnerabilities and risks early in the development cycle before APIs are released.
• API Discovery (runtime) – Performing discovery at this stage is important to help security teams understand the APIs used by different applications and the potentially sensitive data they may be exposing. Discovery at this stage can also help you identify shadow (unknown) and zombie (outdated) APIs not identified in the design-time stage.
• API threat protection (runtime) – Applying security at runtime helps you monitor production APIs for any misuse and stop attackers before exploiting vulnerabilities.

What products help with API security?

Mark and Dionisio outline a number of different product categories that can help improve API security, starting with API management which can include API gateways and portals. Mark is quick to point out that API management only secures the APIs registered with that tool, and it’s common for many APIs to operate outside of the boundaries of API management. 

It’s also important to consider that API management platforms typically depend on security capabilities such as authentication, authorization, encryption, message filtering, and rate-limiting. While these are important foundational security capabilities, they fall short when it comes to protecting APIs. Taking authentication as an example, the Salt Security State of API Security Report 2021 found that 96% of API exploits happen against authenticated APIs. Also, as pointed out above, many attackers take advantage of commonly found authorization flaws – defined as BOLAs, the number one threat on the OWASP API Security Top 10 list.

Next, Mark covers Web Application Firewalls (WAFs) and points out that many in this category depend on nothing more than traditional application security methods to protect APIs. These methods include the use of signatures to look for known attack patterns, and since each API is different with unique vulnerabilities, the use of signatures is ineffective. It’s also important to note that these proxy-based solutions lack the architecture needed to understand the context of APIs and, therefore, cannot understand the unique logic and cannot identify attackers targeting unique vulnerabilities.

Mark next mentions that many new API startups focus on the challenge of securing APIs, and it’s important to think about API security in a three-dimensional way that includes API security testing, API protection, and API access control. Organizations should consider a combination of products when it comes to protecting APIs and need to make sure that collectively their security stack provides security for both North/South and East/West traffic. Questions to ask vendors to understand their capabilities include: How do you discover APIs? How do you monitor and detect anomalies? And how do you block attacks on APIs?

Another important note is to think about not only what goes into the API such as who is using the API and is the input legitimate or malicious traffic, but also what the API returns in a response. Leaky APIs continue to be a problem and something many organizations overlook. Security tools must also analyze API responses to ensure that the API is not returning an excessive amount of data (OWASP API3: Excessive Data Exposure), especially sensitive data or an error message with too much information included.

Gartner’s Recommendations

Mark and Dionisio wrap up the discussion with the following three main takeaways:

Include your security team – Security and engineering teams can collaborate from the API strategy stage and should work together at every point in the API lifecycle to ensure security. Collaboration is essential given the increasing number of APIs used in application environments, the frequency of change those APIs undergo on a regular basis, and the potentially sensitive data that they expose.

Consider the whole picture for API security, not just the API gateway – In the past, the common thought was that a gateway was all you need to protect APis. However, API gateways don’t always apply to all APIs, and they have limitations when it comes to providing the security needed to protect APIs from attacks. API security needs to extend beyond the foundational capabilities of authentication, authorization, encryption, message filtering, and rate-limiting.

Think North/South as well as East/West – This can require different products, technologies, and strategies to ensure complete coverage. The important thing is not to think of your API products merely as gatekeepers but rather to look for tools that can help you to monitor usage, look for misuse, and stop attacks.

Protecting your APIs

Salt Security is an API protection solution built on big data, AI, and ML to help customers discover all APIs and exposed data, stop attackers early in their process, and provide insights to developers to enable a model of continuous improvement for security. Salt has a flexible, easy model for deployment, does not require changes to application code, and is not inline, so there’s no impact on developers or applications. 

If you’re building APIs to power your applications, reach out for a personalized demo to learn how Salt can make your APIs attack proof to protect your customers, your data, and your business.

‍

*** This is a Security Bloggers Network syndicated blog from Salt Security blog authored by Chris Westphal. Read the original post at: https://salt.security/blog/insights-into-gartners-tips-for-protecting-apis