Combating API Vulnerability

By CIOReview | Friday, June 23, 2017

Monolithic software applications are fast turning into remnants of the past. The focus today is more on a modular approach, where the entire software is developed in modules integrated using APIs. While the       certainly has its advantages, it also brings to table a set of vulnerabilities that need to be dealt with effectively—failing which enterprise data runs the risk of being hacked. This is attributable to the programmable nature of APIs, which the hackers are trying to exploit by writing codes. It is in this context that the breaking up of applications into modules becomes a matter of concern, as doing so creates more interfaces with each being vulnerable to hacking. Therefore, working with APIs requires developers to ponder over how best they can manage the security.

Nature of API Threats

By allowing one software to be plugged into another, APIs tend to expose the interfacial layer between the two—called ‘attack surfaces’, making them vulnerable to hackers. For example, developers can integrate Salesforce with their enterprise applications using the appropriate APIs. The integration process essentially results in the application, accessing data from Salesforce database. If hackers inject malware or any other script containing hacking functions into Salesforce database, through which client systems access the data (by means of the API), and Salesforce fails to get rid of it from its database, then all the data that is being routed to client systems, runs the risk of being hacked.

Challenges in Managing API Security

While organizations—publishers and consumers have begun to take cognizance of the threats associated with APIs, combating them has also proved to be a challenging task. However, two factors that pose a challenge are:

Reducing Attack Surfaces: As the threat magnitude is directly proportional to the ‘attack surface’ area, it is obvious that reducing the area, is effective in combating the threat. However, shrinking the interfacial area potentially amounts to compromising on the intended functionalities and therefore, balancing the two is a major challenge. This is because the API design process is usually optimized to include only the required number of interfaces to provide the intended functionality.

Usage of Multiple Programming Languages: Different APIs are programmed in different languages. For example, a Web API such as ADSafe is implemented in Javascript while a Firefox extension API is done so using both C++ and Javascript. In such a situation, organizations require experts in multiple domains to assess the security requirements of the API in question.

Business Factors: Organizations publishing APIs, often do so to support business initiatives mobile or plug and play support and measure their success only by the degree of customer engagement and agility support provided. Since the API consumption assumes the primary role, security more often than not gets pushed to the second place.

Absence of Documentation: When the API being used by a developer to perform software integration, understanding the exact formats of data flow or exchange between the modules, becomes a challenge. This naturally impacts the process of managing the API security.

Managing the API Security

To plug all the loopholes in API security, developers need to ensure that zero latent vulnerability in the API. Consumers can verify the safety by understanding thoroughly all aspects of API functions, the various function calls in the code, required authentication and the security standards that the API confirms with, among many others. Documentation plays a crucial role in understanding the concepts and therefore, the usage of well-documented APIs is always recommended for consumers.       

The onus of combating API-related threats also lies on companies building them. Developers must prioritize building appropriate routines to control and validate the exchange of data from the servers to the client systems, through the API. Appropriate features to prevent the entry of malicious scripts into the database should also be incorporated to prevent hacking attempts.

Companies building APIs for their internal use should control access to them and clearly define the scope of activities that each employee can perform, with respect to an API.