{"id":7068,"date":"2025-01-24T13:14:06","date_gmt":"2025-01-24T19:14:06","guid":{"rendered":"https:\/\/www.darkreading.com\/cloud-security\/3-use-cases-for-third-party-api-security"},"modified":"2025-01-24T13:14:06","modified_gmt":"2025-01-24T19:14:06","slug":"3-use-cases-for-third-party-api-security","status":"publish","type":"post","link":"https:\/\/ddi.mohflo.net\/index.php\/2025\/01\/24\/3-use-cases-for-third-party-api-security\/","title":{"rendered":"3 Use Cases for Third-Party API Security"},"content":{"rendered":"
<\/a><\/div>\n
<\/div>\n

COMMENTARY<\/span><\/span><\/p>\n

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.<\/span><\/p>\n

According to a <\/span>recent Gartner survey<\/a><\/span>, 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. <\/span><\/p>\n

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. <\/span><\/p>\n

Three use cases should be top of mind for these security leaders.<\/span><\/p>\n

Use Case 1: Discover and Manage Outbound Data Flows to Third-Party APIs<\/h2>\n

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.<\/span><\/p>\n

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.<\/span><\/p>\n

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.<\/span><\/p>\n

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.<\/span><\/p>\n

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\u2014for example, security service edge (SSE), DLP, and API protection tools all have certain DLP capabilities.<\/span><\/p>\n

\n