Third-party API use is growing, which may be a potential risk for many developers. Leaning on external APIs is necessary for modern software development, but it requires a level of trust that may expose the codebase and the system unduly. Below, we’ll dive into this particular problem and look at some best practices to secure systems that utilize third-party implementations.

Where This Problem Comes From

Part of the magic of APIs is that they can be used in various use cases, both first-party and third-party. The idea that an API can be used across the internet for a variety of interactions and flows is the ultimate promise of the platform effect, and it is one that modern API development and iteration depend on heavily. This kind of external consumption of a first-party resource is broadly called “third-party usage.”

Unfortunately, with this expansive third-party API use comes a bevy of risks. So much so that OWASP now lists Unsafe Consumption of APIs as one of the top threats faced by organizations. Businesses have often trusted third-party API implementations at a level different from typical user input, but this trust can often be misplaced or misaligned, and it depends wholly on ensuring that the other party — the implementer you depend on — has done their due diligence at every possible level. Even when this trust is warranted, the reality is that implementers often choose a different security posture depending on their perceived trust. According to OWASP:

“Developers tend to trust data received from third-party APIs more than user input. This is especially true for APIs offered by well-known companies. Because of that, developers tend to adopt weaker security standards, for instance, in regards to input validation and sanitization.”

The problem here isn’t just about trust, however. Even if a system is implemented well and carries its own secure implementations on the third-party integrator, there’s still a level of obfuscation that cannot be ignored. Compared to open-source tools that provide a view into the internal code, third-party APIs are out of your hands as they operate in a black box.

Ultimately, developers need to adopt some best practices to ensure that their use of third-party APIs is as safe as possible. Let’s dig into these best practices.

Best Practices for Securing Third-Party API Usage

1. Adopt Zero Trust Principles

The premise of zero-trust security is simple: trust nothing, verify everything. While this might seem obvious for external data, the reality is that many threats occur due to internal issues. Many scenarios, such as improperly configured instances, leaning on insecure third-party solutions, or even having a single weak point in the staffed organization, can result in a massive issue of insecurity.

Accordingly, adopting a zero-trust model is the only way to correct the course. Zero trust requires that everything — even internal users and internal calls — must verify that:

• They are who they say they are
• They are accessing what they say they are accessing
• They have all the rights that are required to perform the action

This control is often enabled through fine-grained policy and rights control, with a multi-layered system using varied [claims and role-based enforcement. Put simply, when you trust nothing and everything is automatically suspect, you are already 99% of the way towards securing third-party implementation.

Data validation and sanitization are a big part of ensuring you are correctly ingesting third-party APIs. You never know what an API might send when the API is outside of your control, and blindly trusting the output of anything violates the principle of zero trust. Therefore, it’s a good practice to validate and properly sanitize any data received from integrated APIs before using it.

2. Catalog Use Cases and Implementations (And Audit Them, Too!)

Visibility is a huge element for any security posture, but this is even more true regarding third-party implementations. Obfuscation is the enemy of true security, and when we’re talking about third-party systems, we need a higher amount of visibility and documentation.

Therefore, every single use case and third-party implementation must be documented. This documentation must include the technical details, of course, documenting what third-party system is being utilized, how it’s being implemented, and the dependencies that are needed. Additionally, however, it’s vital to include the logic behind the implementation. Why was this solution used? What does it enable from the business logic perspective? And is it critical for ongoing development?

Answering these questions grants much-needed context, which can help further improve the security posture. For instance, if an integration was made in a rapidly short time frame, this might suggest it should be audited from a security standpoint.

Additionally, OWASP suggests the generation of an allow list for third-party APIs. Maintaining an allowed list of trusted and well-known API locations prevents redirects from being used maliciously, and as long as you do not blindly follow redirects, you can gain substantial security.

Auditing will be a key part of all of this. Review often, trust nothing, and double-check everything!

3. Implement Proper Authorization and Authentication

Developers often assume third-party implementations to be secure, depending on the source. After all, if something is coming from Amazon, it has to be secure, right? Not necessarily. Everything is exposed to attackers at all times, and assuming that a major party is not just at risk as anyone else is setting yourself up for major disappointment.

Accordingly, implementing proper authorization and authentication is vital. Ensuring that these systems exist and implement granular controls is the very least you can do, but it goes further than that.

What happens if a massive security risk requires you to break formerly trusted pipelines? You’ll need to depend on revocable systems such as revocation of tokens. What happens when an administration API gets breached? You better have heuristics-based authentication systems to detect illicit use! Or, suppose a new company has bought a third-party implementation and injected it with malicious code! If you adopt a zero-trust environment, you can automatically reject those malicious endpoints and requests.

Setting up proper authentication and authorization is critical in typical APIs, but even more so in this use case. So, do the right thing and implement this correctly.

4. Establish Rules of Governance

Implementing a trusted system implies that there is something between being trusted and not being trusted. Without clearly defining what that line is, no developer is going to be able to enforce their security posture. Again, obfuscation is the enemy of security here, so transparency is the name of the game.

Every developer should establish rules of governance for their third-party implementations. These should be very clear, but they should also be well-documented, representing the technical as well as the logical implementations, decisions, and reasoning. Clarity at this stage will help clarify when something breaches your rules and becomes an insecurity. Without these rules of governance, you have very shaky ground to stand on.

5. Consider Resourcing as a Team

Not all solutions are technical in nature. Sometimes, third-party integrations rise to a different level. When your codebase substantially utilizes third-party implementations, that’s one thing. When can it literally not function without them, or enable critical functions through them? That becomes a potential business exposure.

In such a case, resourcing an entire team starts to make more sense. Establishing a team whose sole purpose is to govern and secure third-party integrations might seem outlandish, but what we’re looking at is the prevention of a chokepoint through proper resourcing. If preventing this business crunch just means spending a bit more money and time on a team, then that is really an obvious solution.

6. Monitor Third-Party Implementation through Centralized Observability

Visibility is critical for the secure implementation of third-party systems, so anything that can be done to boost this visibility is going to be critical. Consider implementing a centralized observability plane through the use of dashboards, tracking systems, and other solutions. By collecting the entirety of your third-party performance on a single view, you can start to see how this body of code is acting and interacting with your service, allowing for invaluable insight.

This can also open up options for controls that you may not otherwise have. Heuristics-based systems, automation at scale, and AI-guided security controls all depend on increasing visibility to a high degree.

7. Adopt Proper Management Tools

Developers may also benefit from using API gateways to help control a high amount of third-party implementations. At a certain point, a high enough number of integrations almost becomes an external API in and of itself, and in such a case, a gateway would be warranted to collect those disparate functions and calls into a single source. At this point, you could then use internal security systems to filter malicious calls and control the flow of data.

Even with APIs that don’t have a mass amount of calls, this solution might start to make more sense if you are repeating security implementations in multiple places. Simplicity can be a positive element in a security posture, as it prevents overlooking configurations that may result in increased exposure.

Conclusion

Ultimately, third-party implementations should be seen for what they are: powerful options that nonetheless present a potential inflection point for security postures. Adopting proper security forethought around these implementations can lead to extensibility and scalability with increased security and more positive outcomes. On the other hand, an improper security posture around third-party APIs could expose you to fundamental risks. Accordingly, do your due diligence and ensure implementation is secure at all costs.

What do you think of these best practices? Have we missed anything that you would add to this list? Let us know in the comments below!