API Implementation: 4 Key Areas To Ensure Good Security Hygiene

Regardless of whether a company is deploying APIs that they have built themselves or are using third-party supplied APIs, they must secure them. In this post, Ryan Allphin, CPO, Zix, lays out four areas to focus on to ensure good API hygiene.

Application programming interfaces (APIs) are a great way for developers to simplify the coding process and can grant access to a wealth of data and resources that would not otherwise be accessible. This, in turn, provides benefit to consumers who are looking for more (sometimes disparate) information & program workflow synergies at their fingertips in one application.

There are clearly many opportunities for good API use through existing and new innovations.  Unfortunately, as with many things that are good and being used widely, APIs are also a ripe target for threat actors (the bad guys) to exploit, which is why it’s important to focus on secure API practices to mitigate their inherent security risks. Regardless of whether a company is deploying APIs that they have built themselves or are using third-party supplied APIs, the need to secure them and ensure good API hygiene is critical to reducing risk exposure.

In this post, I will suggest four areas to focus on when developing a secure API practice.

Where API Vulnerabilities Lie

Oftentimes API vulnerabilities originate from poor coding practices where the implementer does not safeguard against the failure conditions and prioritize security in the design. This is especially true with third-party open APIs where possibly multiple sources become the author of the API with no standardized, secure framework. This is exacerbated by the fact that it is unclear who is responsible for securing open APIs – is it who developed the open API, or does it fall on the developer who is using and extending it? Where the onus lies for ensuring secure coding practices is still very much a gray area. But without a clear understanding of accountability, the threat of an attack is very high.

In that same vein, there is a risk when the API user lacks the knowledge of what the peak threshold of the API subsystem is prior to extending it. If you do not have an adequate activity logging system to understand who has access to and is using your API, and there’s no max load limit in place, your system can crash. This is when a lot of denial-of-service (DoS) attacks occur, where an attacker will flood an API with connections from different sources, causing the system to overload with no failover relief. 

Learn More: How to Scale Cybersecurity as Your Startup’s Attack Surface Evolves

Implementing Good API Hygiene  

1. Prioritize secure coding practices: API security cannot be an afterthought or pushed as “someone else’s problem.” Organizations can gain a lot using APIs, but they also have a lot to lose when APIs are unsecured. Developing secure practices start with doing an inventory of and management of your APIs. Surprisingly, there are many who don’t conduct scans to discover and inventory APIs in use. Once this is done, working with the DevOps teams to manage and specifically keeping them up to date if they are third-party APIs is key.
2. Activity logging and monitoring: Companies need to have a baseline understanding of how APIs are being utilized and what the normal behavior and load patterns are. That way, if there’s an anomaly or spike in activities, they can either tie it to a specific event or identify when the activity is unusual and is a sign of a potential threat. 
3. Use strong authentication: A major issue with many publicly available APIs is poor or non-existent authentication and authorization controls. Also, this becomes a problem when private APIs are suddenly made public without thinking about auth rights control. These APIs are often a front door to an organization’s databases; it is critical to control entry into that front door and keep it “bolt locked” to those unknown.
4. Know what data can be accessed and transferred: APIs usually allow access to functions and capabilities which come with the ability to pull or transfer data. With that in mind, and as data regulations continue to expand both nationally and globally, knowing what data is being transferred and, within your own system, where it’s being transferred to is necessary to determine if it needs to be obfuscated. Few suggestions here: remove access to information that’s not meant to be shared; encrypt the payload data specifically when dealing with sensitive “identifiable” information; and take responsibility for adhering to data regulations for your solution location footprint.

Learn More: You Can’t Secure What You Can’t See: Defense In-Depth and Network Security

Conclusion

The use of APIs within an organization has arguably become the preferred method to rapidly build today’s applications. However, the concept of “Secure API” use is still evolving as organizations are realizing the potential risks involved. Whether using open or closed APIs, companies of all sizes need to ensure they are practicing good security hygiene from the ground up. That doesn’t mean the only way to be secure is by building their own APIs from scratch and keeping them closed. But it does mean being aware, doing due diligence, and monitoring all APIs when entrusting the security of data and systems to a third party.

Did you find this article helpful? Tell us what you think on LinkedInOpens a new window , TwitterOpens a new window , or FacebookOpens a new window . We’d be thrilled to hear from you.