Skip to main content

API security: gold rush or wild west?

(Image credit: Image source: Shutterstock/Wright Studio)

In today’s world, being constantly connected to people and systems through devices such as smartphones, tablets and computers is pretty much a normal state of affairs. And this ‘always on’ situation will only increase over time - everything will talk to everything else: person-to-person, machine-to-person and machine-to-machine. While this opens up a world of opportunities, the downside is that more and more connections also mean more and more opportunities for attack and compromise. The question remains can you provide adequate security in a cloud age where everything is connected to everything else? 

The good news is that many of these interactions rely on an API (Application Programming Interface) to communicate to an application or system somewhere in the world. APIs have quickly become the primary channel for business transactions in most modern enterprises. When you type in a website address, for example, the request goes out to a remote server belonging to that website that stores the information you require – the API is that part of the server that receives your request and then responds to it. Essentially, the APIs are the connecting technologies that allow the communications.  Or put more simply, APIs are the glue that holds the digital world together. 

Today’s world simply wouldn’t be possible without APIs providing a standards-based way for applications to talk to each other and share data.   

But wherever there is innovation, there is also the dark side of threat and attack, and always someone who will aim to exploit weaknesses. APIs are designed to share data but are not designed to thwart threat and attack. 


One of the core weaknesses of API strategy is the adoption of architectures based on frameworks, toolkits, agents, and adapters.  While these toolkits do indeed provide developers with capabilities to deploy an API architecture, they do not solve the threat problem that gets exposed.    

In fact, too much reliance on the developer, rather than on API security products, is a major cause of API vulnerabilities.  This is not necessarily the developer’s fault.  There are all levels of competency when it comes to developers, but is it really fair to ask all of them to build fail-safe code every single time?  This approach is neither realistic, nor repeatable.  However, this is the foundation of many API architectures today. 

Inconsistent coding, misunderstanding of the ecosystem, and underestimating threat are all strategies discovered only too late, usually in the news coverage of the breach that just occurred. There have been several recent examples of major enterprises being caught off guard.   

In April 2018 it was discovered that a major Identity Access Management company in the Cloud was hacked via an API that exposed the ability to gain access to all 40 million user accounts across 2000 independent customer enterprises that this company was serving.  It is a stark example of how IAM and APIs are integrally tied together, but also how a single API threat can destabilize not only one environment, but thousands. 

In 2017, Instagram reported that it had fixed an API weakness that led to personal information about some of its high profile users, including Justin Bieber, being leaked. Then Google, which owns YouTube, was notified of a flaw in the YouTube code that could allow anyone to erase any video posted by anyone on YouTube regardless of the password and the encryption code. 

API Security – Whose Job Is It Anyway? 

The challenge with API vulnerabilities is that they are rarely easy to spot, and often require specialized technology to detect. But awareness is growing. According to the latest peer-reviewed list of the ten most critical web application security risks (as compiled by OWASP (opens in new tab)), nine of the top 10 vulnerabilities now include API components.

Research from Ovum (‘API Security: A Disjointed Affair’ 2016) has shown that nearly one third of APIs go through specification without being looked at by the IT security team at all. Perhaps the biggest vulnerability is having an API, but not realising it (although everything with a URL has an API). 

As awareness grows, security specialists are beginning to shift their focus towards API security products, rather than API solutions. In turn this is causing many API vendors to reposition themselves as “API security specialists”, adding bolt-on security features to their existing API toolkits, frameworks, and adapter-based solutions in order to placate their customers concerned about API Security.    

The problem with this bolt-on approach is that these API frameworks and toolkits, which offer a single entry point to a system, are not built with security in mind and because APIs are the center point of modern communication, also logically become the central target of attack.  An API architecture centralizes API access control and security, so it must be designed with secure API technologies and architecture principles such as a locked down secure operating system and self-integrity health checks to detect and prevent compromise.  API Security Gateway technology has emerged as a distinct and unique category of API technology where “Security” means the cyber-hardening of the API Gateway product itself so that API enablement can be done securely. 

You need not look very far to understand how industry vulnerabilities can affect insecure technologies.  For example, the recent discovery of Spectre and Meltdown vulnerabilities in the Intel chipset that affected any system running potentially vulnerable 3rd party applications is an example of the risks when the OS isn’t locked down.  These vulnerabilities have left a large number of the world's computer processors exposed over the last twenty years to bugs that made them susceptible to hackers.   However, technologies such as API Security Gateways with locked down operating systems that do not allow 3rd party code to run on the system were not affected by these types of vulnerabilities. 

API toolkit and framework vendors are challenged with retrospectively adding security features to an already insecure baseline, which is akin to adding bars around the windows of a house but leaving the front door open.  These insecure API solutions will be continually plagued with the chicken and egg of exploit and patch, which is the reverse of what you should expect in your API security solution strategy.   Implementing security with a toolkit is a dichotomy.  Would you trust your corporate firewall to be hand-built by a framework or toolkit?        

Three Layers 

An API Gateway that is genuinely secure and able to call itself an API Security Gateway will typically provide three layers of fundamental protection:  

1. Secure, Locked-Down OS to detect and prevent compromise and ensure the inability to break the security model of the system by installing 3rd party applications or having root shell access to the operating system.   

2. Cyber-Secure Policy Enforcement Points (PEPs) to allow secure enforcement of the authentication and authorisation of users within any Identity Management ecosystem.   

3. Real-time Protection and Monitoring to proactively monitor and enforce compliant traffic to applications and services, and take protective measures if threats are detected.   

We are in the middle of an API revolution and APIs are seeing explosive growth in every industry sector around the world. We are witnessing the beginning of a new Gold Rush as IT security experts rush to stake their solution’s claim as the most secure approach. At the moment, there is still a sense that we are living through a ‘Wild West’ period of history where IT security experts are competing to define the secure architecture that will prove to be the industry standard. Many of the voices are just adding noise to an already deafening din, while others are giving businesses a false sense of security due to overlooked vulnerabilities in their design.  Toolkits, adapters, and frameworks are not the answer to security, they are the cause of insecurity. 

In the rush to adopt an API strategy, remember, all that glitters is not gold. Bear in mind the security implications of adopting a framework, toolkit, or platform only approach to enabling connections and data across untrusted boundaries. Securing APIs requires API Security products designed for that purpose, not developers and coding to do it. Expenditure on cybersecurity is set to increase. Gartner has predicted (opens in new tab) that worldwide security spending will reach US$ 96 billion in 2018, up eight percent from 2017.   Not surprising since the cost of insecurity will greatly outweigh that amount.     

This means that the ‘gold rush’ is actually to prevent a breach rather than enable one.  Be careful to choose wisely and avoid wasting your hard-earned cash on ‘fool’s gold’.  

Jason Macy, Chief Technical Officer at Forum Systems (opens in new tab) 

Image Credit: Wright Studio / Shutterstock

Jason Macy is the Chief Technical Officer at Forum Systems responsible for innovation and product strategy. Drawing from experience from virtually every industry sector, Jason has helped to evolve the product technology platform to be the global leader in FIPS 140-2 API security and identity.