When we discuss “insider threats,” our minds often conjure up images of intentional malice – a rogue or ostracized employee looking to profit or seek revenge. However, the truth is much less cinematic in nature; rather, a substantial portion of insider threats arise from human mistakes. In fact, the 2023 Verizon Data Breach Investigations Report, which analyzed over 16,312 security incidents, of which 5,199 were confirmed data breaches, revealed that almost one in five (19%) data breaches involved internal actors, who caused both intentional and unintentional harm through misuse and simple human errors.
In many instances, employees remain unaware that their actions might inadvertently introduce cybersecurity vulnerabilities to their organizations. The same can be said within the realm of application programming interfaces (APIs) and the associated risks tied to this building block of applications. Human involvement often plays a pivotal role creating vulnerabilities in APIs.
The discipline of APIs is rife with unintentional insider threats which are becoming more probable as digitalization abounds in modern business and, therefore, should not be underestimated. In today’s digital-first economy, all companies essentially provide some form of online digital services. Whether they are used internally, externally, or to facilitate third-party processes, all of these online services depend on APIs to run.
The downside is – if APIs are not properly secured – organizations put themselves at risk from accidental data exposure and security gaps stemming minor and unintentional oversights or development flaws. This article takes a look at three of the most common API insider threats: lack of security controls, external usage of internal APIs, and deficient API governance.
Lack of security controls
APIs have become a cornerstone of modern digitization efforts, permeating every corner of technology. However, many times, in the rush to offer innovative services, businesses deploy APIs without conducting proper security assessments. Developers may neglect to conduct the proper security auditing, focusing on delivering the new functionality as quickly as possible. This can result in “overly permissive” APIs. For example, if the proper object-level authorizations have not been implemented in development, an API could allow an unauthorized user access to data or unwittingly expose more data than intended.
The API still works and serves its intended purpose but its vulnerabilities can put it at risk for unintentional or intentional abuse through accidental data leaks.
The trouble is that there’s no amount of testing that would reveal this flaw because the API is working as designed and serving its purpose. These “mistakes” must be combated with dedicated API security tooling that has the ability to identify potential points of sensitive data exposure in runtime.
External use of internal APIs
Another risk emerges when internal APIs, designed for exclusive internal usage, are inadvertently exposed externally. Developers typically don’t impose the same security measures on internal APIs as they do on external ones, assuming that access will be confined to employees and internal systems.
However, instances arise where internal APIs become accessible externally—either due to a breach in the environment’s isolation or a developer’s decision to incorporate an API into a public-facing application. An incident involving Australian telecom provider Optus serves as an illustration. In this case, a test environment unintentionally went public, allowing access to an API without proper authentication checks and the company went on to earmark A$140m to cover the cost of this breach.
Deficiency in API governance
The proliferation of APIs within contemporary organizations has also led to what’s known as API sprawl—an overwhelming quantity of APIs that is hard to monitor and manage. To safeguard APIs, a comprehensive and up-to-date inventory of all APIs—internal, external, and third-party—is essential. However, due to the rapid deployment of APIs, inventories and documentation often lag. Without a structured API governance strategy, organizations may inadvertently expose their APIs. It’s impossible for an organization to defend APIs against attacks if they don’t know what APIs exist within their infrastructure. Moreover, many organizations harbor undocumented (shadow) APIs and outdated (zombie) APIs, which further compounds the risks.
The price of negligence
Insider threats can certainly arise from malicious intent, but a significant number originate from simple mistakes, compromised accounts and a lack of vigilance. Inadequate API security controls, improper API utilization and the absence of API governance can all create vulnerabilities that lead to data breaches, account takeovers, or system disruptions.
Given the crucial role that APIs play in safeguarding a company’s most vital information, it has become imperative for businesses to establish structured insider threat programs that include API security as a cornerstone. These programs should identify APIs and employ specialized technologies capable of continuously detecting and monitoring APIs within their environments. With the ability to spot behavioral anomalies in APIs as they are being exercised, businesses can substantially enhance their defenses to protect their most vulnerable assets.
