API Security

API

Today’s software teams are adopting an API-first model for development. Modular API development is the model of choice for some of the largest organizations in the world, used for both their internal operations and their customer-facing applications. In fact, at least 83% of all internet traffic today is driven by APIs

APIs have been one of the accelerators of agile development, and the industry has benefited from the high velocity of updates and the simpler maintenance of smaller, decoupled components. In terms of security, however, the progress of API development has brought with it new challenges and new attack surfaces. Gartner actually predicted that, by 2022, APIs would become the single greatest attack vector for causing data breaches within web applications, and, according to more industry research, “The risk is real – 95% of respondents have suffered an API security incident in the past 12 months, 21% admit they’ve been the victim of an API breach.”

Clearly, as you scale out your API strategy, security needs to be built in. Understanding the potential threats and taking the appropriate security measures helps protect your company as well as the clients using your APIs.

In this whitepaper, we’ll look at API security from the following angles:

• The challenges of API security
• The current solutions and their shortcomings
• An API security strategy that works

The Challenges of API Security

The challenges of securing APIs come from several different directions, Let’s consider each of these in detail.

The API lifecycle

While many security vulnerabilities are exploited after an API has been published, the introduction of those security risks likely occurred early in the lifecycle. Secure practices begin with awareness and adoption of an organization’s overall security strategy at the very start of the API lifecycle, often at the API Design phase.

However, creating organization-wide security standards is difficult because of the myriad use cases, tools, and teams. Many organizations are simply unable to govern how security is layered into the lifecycle.

Even if a company could implement clear security policies around API development, developers might circumvent those policies. They may delay communicating with the security team or bypass an intentional security chokepoint for expediency.

Example: from internal use to public use

Let’s consider an API that was intended for internal use only. The original team designed the API only to be used by people on that team. All of the users were known within the company, so it seemed unnecessary to build robust security and authentication for the API

Another team within the organization finds out about the API and requests to use it for some of their internal operations. The original developers agree, sharing the API with this other group that, frankly, they don’t know as well. However, they’re all in the same organization, so no harm is done.

Not long after, teams across the entire company begin using the API. Eventually, the API is opened up for use by close corporate partners. Before you know it, an API that was originally developed for single-team internal use becomes a public, customer-facing API. Finally, at this point, the original team begins to consider security best practices. But it’s too late now. The risk exposure has already been extensive. Security by confinement—which obviated the need for practices like strong authentication, levels of isolation, and role-based access control—can no longer be assumed. And, the team is too far past the API design phase to incorporate these measures simply and effectively.

Finally, at this point, the original team begins to consider security best practices. But it’s too late now. The risk exposure has already been extensive. Security by confinement—which obviated the need for practices like strong authentication, levels of isolation, and role-based access control—can no longer be assumed. And, the team is too far past the API design phase to incorporate these measures simply and effectively.

Other threats within the lifecycle

Furthermore, several insider threats can make your APIs and API development vulnerable. Some insider threats may be unintentional, such as malware installed on a developer’s computer, resulting in the exfiltration of data or the injection of vulnerabilities into the API code in development.

Other insider threats may be overtly intentional, as in the case of an employee inserting backdoors into the code that they can later exploit to manipulate the behavior of the API.

Finally, insecure coding practices or human error might lead to the introduction of security vulnerabilities during API development. Bugs—including those related to security—are inevitable, no matter how careful the engineers are. Bugs can be minimized with thorough code review and robust testing, but some errors will always slip through.

Access Control

Most security breaches are not targeted at your application code base, but rather involve user account attacks such as credential theft, leakage, and phishing that provide attackers with a broad range of access to victim accounts and the resources that those accounts have access to. Depending on the level of permissions a compromised account might have in your organization, this kind of attack might lead to disastrous consequences.

While Access Management has become somewhat commonplace, we still see many organizations having not adopted methods of more advanced Access Management, such as Multi-factor authentication and advanced auditing, monitoring, and logging capabilities that can help teams know exactly who, when, and how APIs and applications are being accessed.

Inventory Control

As API development composes a majority share of the software development efforts in an organization, the challenge emerges of managing the ever-growing library of APIs. Many organizations, apart from using automated tools for API discovery, may be unaware of many of the APIs developed and used by their teams. Manual documentation doesn’t equate to proper tracking and systematic updating of an API library list. Because documentation is seldom the primary concern of API developers, updating an organization-wide inventory of existing APIs is overlooked or done in a non-standard manner.

Related to inventory control is the difficulty of ensuring that old APIs are sunsetted or replaced with updated versions. Recall from the previous example that APIs may often be distributed to partners or other departments through unofficial channels. As a result, it can be difficult to track down where older versions of an API are being used, replacing those with newer—and more secure—versions.

Understanding and prioritizing risk

When it comes to security, some APIs are more important to protect than others; prioritization often depends on the types of data an API handles and the level of risk associated with that data. APIs that deal with sensitive data such as financial transactions need to receive special attention from the security team. However, many companies are unable to identify which of their APIs fall into these high-risk categories. Without a focus on proper security, APIs that handle sensitive data can be accessed by malicious actors, and that data is at risk of exposure

Because of this, its important to consider what kind of data your APIs are handling and categorize them appropriately based on risk. The below diagram might help with this:

Recognizing and addressing attack vectors

Of course, the threats to API security can arise from a variety of outside attack vectors. Security needs to cover risks from all fronts.

Client-side risks

In addition to writing secure API code, protection at the client side includes mitigating issues stemming from shared accounts, stolen credentials, cross site request forgery, or other risks.

Server-side risks

SQL injections, improper input validation, and insecure endpoints can all open up the server side of your API to attack. Even though software engineers should know better, they can still fall victim to phishing and social media attacks which may leak their credentials for accessing code or infrastructure. Finally, poor encryption or the mishandling of secrets increases the vulnerability of an API.

Network risks Today’s

API solutions need to take into account not just the software but the entire environment in which the software operates.?

Most companies have invested a fair amount of resources towards preventing network risks such as credential theft or denial of service. Still, even with the implementation of different perimeter protection solutions, organizations cannot ignore the potential risks that can come to their APIs through the network.?

The Current Solutions and Their Shortcomings

The Current Solutions and Their Shortcomings The challenges to API security are many. And while there are some solutions to some challenges, it’s important to understand which challenges these solutions actually address, and where these solutions fall short.