6 Potential Risks of Using Third-Party APIs

Imagine you’re driving on a long road and come to a tunnel that will cut your journey time by a couple of hours. You pull up to the barrier and say, “Hey, can I get through here?”

“Sure!” The attendant replies. “We’ll just load up your car on the back of that truck, I’ll drive it through, and I’ll meet you on the other side.” Would you hand your keys over without checking the attendant’s license, the condition of the truck, or whether they have insurance?

The metaphor isn’t subtle, but it’s essentially what many developers do when they sign up for and start using third-party APIs without vetting them first.

According to Gartner’s 2024 API Strategy Survey, 82% of respondents use APIs within their organization, and a massive 71% are using APIs provided by third parties (SaaS vendors). Without the right measures in place to ensure safe implementation, that could be a problem.

Below, we’ll look at some of the motivating factors behind the growth in third-party APIs, how careless consumption of them can result in problems, and a few ways to mitigate those risks.

1. Blindly Trusting Data From Services

Almost three out of every four organizations now rely on third-party APIs to one degree or another. As companies rush to integrate generative AI into products, which is facilitated by products like OpenAI’s APIs, we should expect to see that 71% figure quoted above rise even higher.

The problem is that, as certain APIs become the de facto status quo, we may be inclined to trust the data they return without question. That problem isn’t limited to APIs associated with genAI, which has a reputation of its own for producing questionable content, but extends to those that have formerly been considered ‘gold standard.’

Take, for example, a wave of recent complaints that Google Maps is getting worse. Their APIs have been used by Domino’s, Uber, and millions of other organizations. Even as some voice concerns about route selection and data freshness, companies continue to flock to it. No matter how high profile its provider may be, we should never assume an API is infallible.

2. Hallucinations and LLM Risks (For Third-Party GenAI APIs)

In a recent post on boosting product features with generative AI, we mentioned how Air Canada is being forced to match a discount promised by a chatbot. Canadian courts determined that the chatbot could not be held responsible as a separate legal entity, which is significant if you intend to white-label API-driven genAI offerings within your own products.

In fact, OWASP lists overreliance on LLMs in its Top 10 For LLM Applications. According to OWASP, “systems or people overly depending on LLMs without oversight may face misinformation, miscommunication, legal issues, and security vulnerabilities due to incorrect or inappropriate content generated by LLMs.”

While that doesn’t mean you should disregard the value that genAI APIs can add entirely, it should be an important consideration throughout the implementation and evaluation process.

3. Improper Input Validation on Incoming Data

Talking about the unsafe consumption of APIs, OWASP posits that some developers may be too trusting of data received from third-party APIs. They may even, especially in the case of well-established APIs, adopt weaker security standards as a result.

Syntactic and semantic input validation can reduce the impact of SQL injection and other attacks. Doing so could involve verifying the syntax of structured fields or the contextual correctness of values. Regardless, input validation should be considered when dealing with data from third-party APIs.

We recently wrote about trying to hack your own APIs. Considering external APIs and data sources that your product interacts with should definitely be a part of this API security testing process. It’s also worth looking at other measures API providers take to defend their services.

Related: How to Implement Input Validation for APIs 4. Outages, Denial of Service Attacks

Many API providers feature status pages detailing uptime, past incidents, and other relevant information. OpenAI’s API uptime, for example, stands at 99.86% at the time of writing. Looking at the time taken to resolve issues, along with the overall uptime of a service, will give you some insight into how responsive companies are to issues relating to outages.

DDoS attacks represent a significant threat to third-party APIs, and rate limiting is a good way to prevent that. In our recent guide to rate limiting success, we talked about how valuable this method can be for mitigating the impact of data breaches. Does the service you’re considering use it?

In an ideal world, API providers will feel comfortable enough with their uptime and rate limiting stats to share them with end users. If they’re hesitant to do so, it’s worth asking yourself why.

5. Versioning or Breaking Changes on Client-Side

Releasing new versions of an API is, generally speaking, a good thing. API versioning implies a desire to fix ongoing issues or add new endpoints/parameters to responses. The downside, however, is that excessive versioning can result in breaking changes. These can leave you as the API consumer struggling to implement a hotfix until documentation is updated to reflect the necessary changes you need to make within your applications.

Sometimes, developers will continue to host documentation that concerns deprecated versions of their API(s), along with supplementary information about major changes they’ve made to the service. Looking at this holistically can help parse how often the company changes its API(s), whether they’ve had significant issues in the past, and more.

6. Improper Inventory Management and Shadow APIs

As outlined in OWASP’s API Security Top 10, Improper Inventory Management poses a significant risk to APIs when, say, old API versions or zombie endpoints are left running unpatched or using weaker security requirements.

In the case of shadow APIs, organizations may not be managing or securing an API at all. Trying to spot documentation (and data flow) blindspots is always a sensible move before you commit to using an API. OWASP suggests looking for things like the following:

• Clarity around the purpose of an API host and who has network access to the API
• Which API version is running, and retirement plans for API versions
• Visibility of flows and whether/how much sensitive data is being shared

Look at whether or not the API’s documentation is up-to-date, thorough, and completely transparent. Also, does it conform to an existing standard like the OpenAPI Specification?

Also read: The Undercurrents of Third-Party API Consumption Management Final Thoughts on Using Third-Party APIs

Unfortunately, building on someone else’s land always carries some degree of risk. As we’ve seen above, relying on third-party APIs that aren’t properly secured or are unreliable in some way could be a recipe for disaster. Or, perhaps more likely, it might just lead to mild frustration.

As the API-first design movement gathers steam, not to mention the mounting pressure to integrate genAI capabilities using AI and LLM APIs, we expect to see even wider consumption of APIs in 2024 and beyond than we’re already seeing right now.

The performance of third-party APIs — uptime, versioning, how they’re secured — has always been important. Still, the extent to which many organizations now rely on them underscores the importance of ensuring their quality before you engage with them. If you weren’t as thorough as you could have been, it’s not too late to audit existing integrations.

As an API developer, you already know what the hallmarks of quality look like when it comes to APIs. If a third-party API demonstrates flaws that you wouldn’t be happy with in one of your own APIs, it’s probably best avoided. Or, to return to that earlier metaphor, look for another tunnel…