OpenAPIs and Third-Party Risks

With APIs, details and specifics are vital. Each API usually takes in very specific requests in a very specific format and returns very specific information, Sammy Migues, principal scientist at Synopsys Software Integrity Group explained. You make the request and you get the information. APIs can be constructed in different ways, but one of the most common forms of web-based APIs is REST.

OpenAPI Standardization

“OpenAPI is a standardization of formats for REST APIs—a way for all people working on any REST APIs anywhere to have a common way to describe those APIs,” said Migues. This includes the API endpoints, authentication methods, parameters for each operation the API supports and then contact information, terms of use, licensing and other general information.

By standardizing this collective documentation, it is easier for developers to understand the software and know exactly how it will behave in different circumstances.

Developers turn to OpenAPI, like they do with any open source software or component, as a way to use code that’s already out there and has already been proven to work. It saves time, gets the software into production faster, is cost-efficient, integrates workflows and is easy to implement.

OpenAPI may also improve applications’ security posture by using the documentation format, according to Gabe Rust, cybersecurity consultant at nVisium.

“Using standardized documentation allows security testers to more easily understand test APIs,” said Rust. “Because using formats like OpenAPI provides more transparency to users and testers, it prevents the pitfall of a big security mistake: Security through obscurity.”

This allows security testers to provide more comprehensive coverage of applications, Rust added. Potentially serious security issues are more likely to be discovered and patched before damage is done.

You could say that security is a feature of OpenAPI, but that’s not to say that it comes without risks.

The Looming Third-Party Threat

Any time you introduce third-party software into architecture, you also introduce risk.

“Third-party web APIs can access sensitive data/information which can increase security risks such as data breaches,” Deepak Gupta wrote in a blog post.

Like any software or application, APIs can be infected with malware, and that can create a lot of damage for a web project, the organization and consumers.

OpenAPIs aren’t immune to security risks. They can be hacked, of course—nothing is totally immune from being attacked—but the most serious threats come from third parties. With openAPIs comes data sharing, and the data shared can include personal information or corporate intellectual property, unwittingly made available to third parties.

OpenAPI security is fairly limited, said Jeff Williams, CTO and co-founder at Contrast Security. “It simply allows development teams to define the authentication scheme to be used with each API. This is useful to help prevent unauthenticated endpoints from exposing critical data and functionality.”

Unfortunately, it doesn’t protect APIs against attacks from authenticated users. “Unless you fully trust all of your users, you should be very concerned about the long list of vulnerabilities that APIs can have, such as, for example, various types of injection, unsafe deserialization, server-side request forgery and libraries with known vulnerabilities,” said Williams.

In OpenAPI, it is impossible to know, let alone trust, all the users. To protect sensitive data from third-party risks, it may be necessary to evaluate the use of OpenAPIs and the type of information they have access to. Protecting sensitive data and preventing data breaches from third party intrusion should be of the highest priority when using OpenAPIs.

Avatar photo

Sue Poremba

Sue Poremba is freelance writer based in central Pennsylvania. She's been writing about cybersecurity and technology trends since 2008.

sue-poremba has 271 posts and counting.See all posts by sue-poremba