When organizations consider application programming interface (API) security, they typically focus on securing APIs that are written in-house. However, not all the APIs that companies use are developed internally, rather some are designed and developed by other organizations. The problem is that many companies don’t realize that using third-party APIs can expose their applications to security issues, such as malware, data breaches, and unauthorized access.
Third-party APIs are software interfaces that allow organizations to leverage third-party functionality or data on their own websites or applications. These third-party APIs enable developers to integrate their applications or systems with external services, data, or functionality, says Phil Quitugua, director of cybersecurity at technology research and advisory firm ISG.
Some popular third-party APIs include navigation apps, social media platforms, and digital payment processing tools. “These are APIs that third parties, such as Google or Facebook, for example, make available to allow you to access their data or functionality on your own website or app,” says Paul Scanlon, vice president of product at DataDome. “Everybody loves APIs. By enabling all kinds of devices and applications to exchange information via all kinds of communication protocols, APIs help developers create great user experiences much more easily and efficiently.”
But within the ubiquity and popularity of APIs lies a security Achille’s heel — about 94% of companies have experienced security problems in production APIs within the past year and 17% were subject to an API-related breach, according to the State of API Security Q1 2023 report by Salt Security. Hence, the need to implement security for third-party APIs.
Why it’s so important to ensure the security of third-party apps
Third-party APIs need strong security because they can be weak points, says Jim McKenney, practice director, industrials and operational technologies at NCC Group. If they’re not secured, they can leak sensitive data or cause problems with the original software.
“API security protects communications between programs, such as OpenStreetMap’s API, from cyber threats,” says McKenney. “It defends against malicious attacks, unauthorized access, and emerging threats like API abuse. API security ensures secure and authentic conversations between applications.”
Third-party API security involves implementing measures such as authentication, authorization, encryption, and monitoring to ensure the privacy, integrity, and availability of the API and its data, says Doug Ross, vice president of insights and data at Sogeti, part of Capgemini. “API security is a critical aspect of software development as APIs often serve as a bridge between different systems and are increasingly used to exchange sensitive and critical information,” Ross says.
Ensuring the security of third-party APIs is crucial for many reasons. For one thing, APIs can access sensitive information, such as user data or payment information. So, if a third-party API is compromised, it can lead to data breaches that affect both the end-users and the businesses relying on the APIs. Additionally, insecure APIs can expose applications or systems to vulnerabilities and attacks, potentially causing system failures or inappropriate access to resources.
The security of third-party APIs is also important in the maintenance of compliance, as many industries have strict regulations around data protection and privacy, for example, the EU’s General Data Protection Regulation (GDPR) and the United States Health Insurance Portability and Accountability Act. Ensuring the security of third-party APIs helps organizations comply with these regulations and avoid penalties from oversight bodies, Ross says.
And a security breach involving a third-party API can damage the companies’ reputations, leading to a loss of customer trust and potentially affecting business partnerships.
Here are five best practices to ensure the security of your third-party APIs:
Maintain an API inventory that includes third-party APIs
Maintaining an API inventory that automatically updates as code changes is an instrumental first step for an API security program, says Jacob Garrison, a security researcher at Bionic. This is an instrumental first step for an API security program; it should distinguish between first-party and third-party APIs. And it encourages continuous monitoring for shadow IT — APIs brought on board without notifying the security team.
“To ensure your inventory is robust and actionable, you should track which APIs transmit business-critical information, such as personally identifiable information and payment card data,” he says. An API inventory is complementary to third-party risk management, according to Garrison. When developers utilize third-party APIs, it’s worthwhile to consider risk assessments of the vendors themselves.
“For example, suppose your data engineering team wants to send personally identifiable data to Tableau for analysis,” he says. “In that case, it’s worth assessing whether that vendor’s security posture is within your organization’s risk tolerance.”
Frank Catucci, chief technology and head of security research for Invicti Security, agrees that including an inventory of third-party APIs is critical.
“You need to have third-party APIs be part of your overall API inventory and you have to look at them as assets that you own, that you are responsible for,” he says. “So, making sure that you have an accurate count of which APIs are running where and what they are doing is an important first step because you can’t secure what you don’t know.”
Investigate third-party API vendors
Organizations should choose reputable providers with strong security measures, monitor API activity for suspicious behavior, and use encryption, according to McKenney. For example, use a payment processing API only from a trusted provider, regularly monitor the API logs for any unusual activity, and ensure that all sensitive data sent through the API is encrypted.
For third parties, it is important to build out a vendor security management process, says Bryan Willett, chief information security officer at Lexmark. “That process should be tightly integrated with your procurement process, such that all vendors and contracts go through the process,” he says. “The process should consist of a few sub-processes, including vendor risk assessment, vendor security scoring, and ongoing monitoring as well as a contractual review to ensure the terms fit within the risk tolerance of the organization.”
Ensure vendor security testing of third-party APIs
It’s important that companies establish their vendors’ general security controls as well as the security controls across the different stages of the lifecycle of the third-party API to ensure the appropriate protections meet their risk tolerance, Willett says.
“As an example, you want to see a security development lifecycle ingrained into the organization’s culture from training to gates throughout the delivery process to ensure security is thought about from the beginning,” he says. Those gates should include practices that address the risks created by the source code developed by the vendor and open-source libraries included in the product, according to Willett.
“You want to see that [the vendors] have good security testing practices using both the latest in tools to perform static code analysis, fuzz testing, and vulnerability scanning,” Willett says. “In the operational space, you want to see evidence of a strong change management process with appropriate access controls on the data and implementation of zero trust principles.”
Vendors should also have mature vulnerability management programs monitoring the operational environment for patches and a defined service level agreement for when vulnerabilities will be patched.
Test third-party APIs yourself
Even though organizations didn’t write third-party APIs and don’t control them, Catucci says they can still test them as they would their own APIs. For example, companies could use dynamic application security testing capabilities to scan third-party APIs for known vulnerabilities, vulnerable components, or out-of-date components that may exist within those APIs.
“You still have to test them even if you don’t own them,” he says. “If you find that a third-party API has a specific vulnerability, you may want to block that functionality or not use that API until it’s fixed.”
Rotate API keys
Another security consideration is the rotation of API keys, Willett says. When a user calls a third-party API they must provide a unique string with their request, known as the key. This string tells the vendor which customer is making the call. Rotating keys regularly is necessary for two main reasons.
“First, a bad actor intercepts your API key, then they can generate requests on your behalf. Depending on the security protocols used by the third party, this key may be sufficient to extract sensitive information associated with your account,” Willett says. “Second, third-party APIs cost money. API keys are used for billing purposes. A malicious actor can rapidly fire API requests using your key to drive up your bill. For these two reasons, an API security program should include regular key rotation.”
The bottom line: don’t leave APIs unprotected
API-based attacks are highly sophisticated, requiring equally robust defenses. Even more, third-party breaches are more prominent now than ever, says Jeremy Ventura, director of security strategy and field chief information security officer at ThreatX.
“Many high-profile security breaches like Peloton and Nissan resulted from unprotected APIs,” he says. “Attacking an organization’s supply chain is very attractive for cybercriminals looking to get a foot in the door of a network.”
Consequently, it’s critical for companies to understand that third-party API security threats are not just an IT problem but a core business problem impacting all organizations and customers involved, Ventura adds.
Copyright © 2023 IDG Communications, Inc.
