3 Use Cases for Third-Party API Security3 Use Cases for Third-Party API Security

COMMENTARY

API security often involves third-party, rather than first-party, APIs, and each use case can have different requirements. Rather than trying to make one technological approach work for all instances, security and risk management leaders must adapt their approach to the specific use case.

According to a recent Gartner survey, 71% of IT leaders report using third-party application programming interfaces (APIs) in their organizations. Many security and risk management leaders must focus on API security when dealing with consumption and integration with third-party APIs, rather than exposure of first-party APIs. 

In addition, when it comes to third-party APIs, many remediation measures, such as patching for exposures, are not under the organization's direct control. Therefore, the approach will have to be fundamentally different as compared to first-party APIs. 

Three use cases should be top of mind for these security leaders.

Use Case 1: Discover and Manage Outbound Data Flows to Third-Party APIs

In this first use case, the enterprise sends data to third parties via APIs, typically by invoking them from homegrown applications. In an e-commerce scenario, for instance, the service providing the API could be a payment gateway. In this example, the outgoing traffic would contain payment data used to process a payment. There are different ways to invoke the API from within the application, such as direct integration, using a software development kit or a webhook.

A main risk is that sensitive data may be sent toward the API. This activity may conflict with enterprise policies or industry regulations. Third-party APIs may also put the data, or the data of customers, in danger. For example, an attacker may be able to steal payment data from customers by using a vulnerable payment API. Depending on the scenario, injecting a malicious payload could also corrupt the database of a business partner.

In this scenario, security leaders should discover third-party APIs by performing traffic inspection, code repository inspection, and software composition analysis, as certain third-party APIs may be invoked via third-party libraries, not homegrown code.

Security leaders should also liaise with the team that manages sourcing, procurement, and vendor management (SPVM) and third-party cyber-risk to ensure software-as-a-service (SaaS) applications are vetted and comply with organizational policies.

Security leaders must also identify sensitive data exfiltration by monitoring the outgoing traffic in these API exchanges. This is typically achieved by implementing data loss prevention (DLP) capabilities. Disparate tools could apply—for example, security service edge (SSE), DLP, and API protection tools all have certain DLP capabilities.

Finally, security leaders can implement proper authentication and authorization of the API client (in this scenario, the application) using the mechanisms offered by the API provider. At a minimum, favor tokens over API keys for authorization. Assess how opaque and proof-of-possession tokens (or at least frequently rotated access credentials) and certificate pinning may efficiently mitigate token leakage and interception risks in specific use cases. Be mindful of the technical burdens they may require to set them up and issues with traffic inspection.

Use Case 2: Protect From Inbound Traffic From Third-Party APIs

In this use case, the organization consumes the third-party API, and the data is incoming. A typical example could be an enterprise application that makes an API call to obtain data from a commercial SaaS provider or a business partner.

One risk in this use case is receiving potentially harmful input from the API. Malicious input from third-party APIs may endanger applications, its users, or the infrastructure hosting applications. For example, if an API response with a malicious payload is sent to a database, it could result in an injection attack.

Data exfiltration is still a risk for this use case, and many of the recommendations from the first use case still apply here. If the outgoing API request contains sensitive data, that data could be intercepted. For example, if an API call requests a list of restaurants based on GPS coordinates, said GPS coordinates could be intercepted if the connection is not secure. Most importantly, the third-party API could be fetching the specific data of the enterprise. (Think, for example, of an API fetching data about customers from specific instances of a CRM SaaS application.)

Security leaders should perform input validation. Ask developers to add input validation controls when ingesting any input, including input from third-party APIs. This will prevent a large spectrum of attacks from malicious input, such as SQL injection attacks. Application security testing (AST) tools can help automate these checks.

Use Web application firewall functionality from a Web application and API protection tool in-line to add contingencies against injection attacks and other types of malicious input.

Finally, vet the input with an antivirus, sandboxing, or content disarm and reconstruction solution by integrating applications typically via Internet content adaptation protocol or APIs with one or more of these tools.

Use Case 3: Discover, Vet and Manage the Data for Third-Party Apps That Communicate via APIs

Many security leaders are focused on API security but describe a scenario where one or more SaaS applications typically communicate via APIs, exchanging enterprise data. This issue can be exacerbated because users may be able to interconnect SaaS applications without having administrative privileges. While the underlying communication may be API-based, this problem's solution is closer to the best practices for SaaS security.

This situation is particularly challenging when an authorized SaaS application user connects it via API to an unauthorized SaaS app. Many organizations will have little to no visibility of the connection's existence, let alone of any data transfers across it. Second, visibility is limited to what SaaS providers reveal through their own management APIs, as there's no clear place to insert an in-line control. The main risk with this scenario is that the SaaS application may expose sensitive enterprise data via the API, and that data may be transferred to an unapproved and even unknown location that security has not vetted.

Security leaders should discover the SaaS applications used by performing a census, releasing a policy, and inspecting traffic. Use SSE, firewalls, SaaS management platforms, or other tools to identify the SaaS applications users are accessing, especially those housing sensitive data. Until they know what applications users are accessing, they cannot check for SaaS-to-SaaS connectivity

Discover rogue SaaS access tokens by querying the SaaS applications used, where supported. Create and promote policy to users about connecting SaaS apps via OAuth.

For the previous use cases, liaise with the team that manages SPVM and third-party cyber-risk to ensure SaaS applications are vetted and comply with organizational policies, such as data security and third-party sharing ones. In addition, inventory SaaS-to-SaaS interconnections; automated tooling, such as SSPM offerings, can help ensure this is a continuous process.

By adapting their approaches to these three specific use cases and their possible variations, security leaders can address the risks that third-party APIs present for their organizations.