Mitigate the primary risks to API security

APIs are foundational to modular application development. They support an organization’s internal services as well as provide a mechanism for customers to access certain services or datasets for their own applications. Because of the role that both internal and public-facing APIs play in applications, they are considered one of the top targets for threat actors.

In this post, we’ll look at three types of threat actors that target APIs and some of the main vulnerabilities they can take advantage of.

Threat actors and their motives

Understanding how APIs can become vulnerable is an important part of API security, but it can overlook a fundamental piece of the puzzle: the motive behind attacks. In order to effectively secure their services, organizations need to identify who might attack their underlying APIs and why. For example, why would a threat actor be more interested in an organization’s public-facing APIs than its internal ones? And further, which types of attacks are used to target those APIs, and why? Once an organization understands the actors and motives behind specific types of attacks, they can use that information to take informed action about how to prevent them. For this post, we’ll focus on three types of threat actors that can target APIs: opportunistic, sophisticated, and internal.

Opportunistic threat actors use stolen credentials on already compromised infrastructure resources to launch malicious processes for financial gain, such as unauthorized crypto mining. They may also use their privileged access to an organization’s environment to steal or modify sensitive data, such as payment information on payroll applications. To accomplish this, opportunistic threat actors scan public-facing APIs for sensitive data that they can take advantage of, which is often the result of broken authentication and authorization controls and other security misconfigurations.

Sophisticated threat actors aim to gain access to an application in order to steal intellectual property and data that could be used for ransom. Unlike opportunistic threat actors, this type of threat actor uses advanced social engineering techniques (such as credential phishing) to steal credentials, bypass multifactor authentication (MFA) controls, and access an environment. For cloud-based applications that use metadata API services, credential theft is a growing risk, especially if it’s the result of attacks like server-side request forgery (SSRF). Once they have access, sophisticated threat actors may also search for and take advantage of misconfigured internal APIs in order to discover other vulnerable resources and exfiltrate data.

Internal threat actors can include disgruntled employees, contractors, and vendors who take advantage of their given access—often with elevated permissions—to accomplish the same goals as sophisticated and opportunistic threat actors. These attack scenarios are typically the result of ineffective off-boarding processes, which often entail a lack of visibility into the varying levels of access a particular user had.

Even though different types of threat actors target different APIs for various reasons, they all can take advantage of the same security gaps. Next, we’ll look at a few of the areas where APIs are most vulnerable to threat actors and their attacks.

Primary vulnerabilities seen in APIs

The top risks to API security for 2023 fell into three categories: API inventory management, authentication and authorization controls, and resource management. Misconfigurations and broken functionality in these areas can quickly give threat actors access to an API, its supported resources (such as databases), and sensitive data. While some areas are more susceptible to security risks than others, each one plays an important role in how teams address these issues.

Poor Inventory Management

Poor inventory management is one of the primary security risks for APIs, and there are several factors that create gaps in an organization’s knowledge of their APIs. These ecosystems are complex and constantly evolving, especially in cloud environments, so it’s challenging to keep an up-to-date count of all active APIs. And because each API is designed to serve a different purpose and often supported by various teams, their documentation standards may also vary. As mentioned earlier, APIs that are not well-documented risk becoming vulnerable to outdated configurations, broken authorization or authentication controls, and other issues that threat actors can take advantage of.

Opportunistic threat actors, for example, will often gain access to an environment by exploiting older, unpatched versions of public-facing APIs. Sophisticated actors may find shadow APIs to serve as a difficult-to-detect launching point for further attacks, such as DoS attacks. Shadow APIs are API endpoints that are active but not a part of an organization’s managed inventory, making them easy targets due to their often outdated security or compliance configurations.

Documenting and categorizing existing APIs with standards like the OpenAPI specification can help teams efficiently manage all of their APIs and quickly surface any missing, outdated, or misconfigured ones. As an example of how OpenAPI can be used for standardization, the following specification documents a checkout API’s version, endpoints, and responses:

openapi: 3.0.2
info:
  title: Checkout API
  description: This API allows you to perform various operations related to the checkout process, including applying coupons, shipping orders, and delivering orders.
  version: 1.0.0
paths:
  /checkout:
    post:
      summary: Checkout
      responses:
        '200':
          description: Successful checkout
  /ship_order:
    post:
      summary: Ship order
      responses:
        '200':
          description: Order shipped successfully
  /deliver:
    post:
      summary: Deliver order
      responses:
        '200':
          description: Order delivered successfully
  /apply_coupon/{coupon}:
    post:
      summary: Apply a specific coupon
      parameters:
        - name: coupon
          in: path
          required: true
          schema:
            type: string
      responses:
        '200':
          description: Coupon applied successfully

If a team notices that a particular API is outdated or missing an important security scheme, they can quickly update the specification and fill in those potential security gaps.

Instrumentation can help simplify the process of inventorying APIs by using an organization’s existing instrumented services to automatically discover APIs and their endpoints. This is in addition to what’s already documented via OpenAPI specifications. Once all known APIs are documented with standard definitions, teams can use them to start building an extensive catalog of their API ecosystem, as seen in the following screenshot.

Organizations can take this process a step further by augmenting their API catalog with existing runtime data, which provides insight into critical elements of API security, including:

• Which APIs are actively being scanned by a threat actor
• If an API is receiving traffic from the public internet or running in a production environment
• Which types of authentication mechanisms are used, such as API keys
• If an API is processing sensitive data or using a vulnerable, third-party library

This added visibility creates a foundation for understanding how certain APIs are vulnerable and to what extent. As seen in the following screenshot, organizations can start their investigation with the APIs that are running in production and then drill down to specific endpoints that are at risk.

Visualizing this information makes it easier to identify and prioritize the issues that are more prevalent and challenging to address, such as broken authentication controls or overly permissive access to data.

Inefficient authentication and authorization controls

Inefficient authentication and authorization controls are the primary risks to API security, making up four of the ten risks identified by OWASP. Authentication uses mechanisms such as usernames and passwords, API keys, and tokens to verify the identity of a user or service that wants to access an API. Authorization controls ensure that a verified identity has permission to access an API and its data. Both authentication and authorization are necessary for securing APIs, but they can be easy to overlook or configure incorrectly. And because an API’s authentication and authorization controls are the first lines of defense for applications, they are the most susceptible to an attack. Inefficient controls can look like the following:

• Failure to ensure that users have the appropriate permissions to access API resources
• Poorly designed or missing login mechanisms
• Failure to ensure that users have the appropriate permissions to access API properties, such as sensitive data
• Allowing users access to administrative endpoints

In practice, these risks can look like simple design gaps, such as allowing weak passwords for user or service accounts that are accessing an API or embedding authorization tokens or passwords in an API URL. Each of these issues are areas that threat actors will look for and take advantage of. In these cases, an opportunistic threat actor may try to take over an account via methods like credential stuffing or brute force attacks, which exploit leaked usernames and weak passwords. As another example, internal threat actors who are off-boarding may attempt to use their permissions to exfiltrate sensitive data from an associated database before they leave.

There are several steps that teams can take to fix broken authentication and authorization controls. For example, teams can ensure that each of their APIs include some form of strong authentication. As previously mentioned, the OpenAPI standard includes several security schemes that teams can add to their API specifications, such as OAuth2 and OpenID Connect Discovery. These two options are beneficial for third-party applications that need to connect to a particular API.

The principle of least privilege, which recommends giving users or services only the permissions they need to accomplish their tasks, can strengthen an API’s authorization controls. This step is especially important for APIs that interact with sensitive data. If an API has overly permissive access, threat actors—like sophisticated and internal—who are looking for valuable data can easily exfiltrate it if they bypass other controls. In practice, this principle can look like creating an allowlist of user and service IP addresses that are allowed to make requests to certain APIs, such as those that interact with sensitive information. Regularly auditing these permissions can also ensure that existing and newly deployed APIs have the appropriate levels of access.

Measures like these create multiple layers of protection for APIs, but it’s important to understand how an API’s resources can also be vulnerable in order to build a complete security strategy. We’ll take a look at the risks surrounding an API’s underlying resources next.

Unrestricted access to resources

The underlying resources that support an API, such as servers and databases, are vulnerable to targeted threats such as DoS attacks. For example, opportunistic threat actors may attempt to bring an application down by making thousands of calls to a public-facing API in order to exhaust an organization’s network and servers. In this scenario, the vulnerable API allowed unrestricted resource consumption. Threats like DoS attacks are often used as a launch pad for more sophisticated ones. By distracting teams and overwhelming firewalls with a sudden flood of API requests, threat actors can explore other areas of an application—and expose other weaknesses—freely.

Rate limiting, which sets restrictions on how many API requests can be made within a period time, can help prevent this type of activity. Teams can add rate limits to their APIs based on their function or specification. For example, they can throttle how many times a user or service attempts to execute an API operation, such as deleting an account, within a short period of time.

Setting up web application firewalls can also automatically block these types of calls from suspicious IPs, creating an extra layer of protection from DoS threats. These safeguards, in combination with a complete API inventory, efficient authentication and authorization controls, and appropriate permissions, can ensure that APIs are safe from threats.

Enhance your API security strategy

In this post, we looked at the top risks to APIs, as well as the different types of threat actors that target your APIs and their motives. We also looked at recommendations for securing both your internal and external APIs to guard against these attacks. To learn more about how Datadog supports your APIs, check out our API Catalog documentation and API security documentation. If you don’t already have a Datadog account, you can sign up for a free 14-day trial.