Understanding the basics of API security
This is the first of a series of articles that introduces and explains application programming interfaces (API) security threats, challenges, and solutions for participants in software development, operations, and protection.
Purpose of article series
Researching the wide range of API security alternatives can be confusing – even to seasoned experts. This article series is written with the goal of helping all types of readers better understand the pros and cons of the various modern approaches to protecting APIs from cyber security risks. The material is intended to help enterprise security and software development teams develop and maintain a consistent protection philosophy.
The target reader includes software developers who depend on and use APIs every day, as well as technical managers who might have responsibility for API security in their organization. The target reader also includes, however, technical-minded individuals possessing little experience with APIs, but who are nevertheless interested in the security aspects of this important issue. We try to describe the API security concepts in a manner accessible to each type of reader.
Introduction to APIs
The typical user of network and Internet services tends to think of computer interfaces in terms of screens, keyboards, monitors, and the like. These interfaces are the visible means by which systems exchange information with human users, and they have advanced rapidly in recent years. The touch screen from Apple, for example, emerged only a decade ago, and a generation of youngsters barely remembers what the world was like before such useful capability existed.
But there is another type of interface that exists in computing, perhaps more hidden to the everyday user. This other type of interface is how software programs communicate with one another. For many years, this process was poorly specified, with programmers inventing protocols for something called inter-process communication (IPC). An early operating system from Bell Laboratories called Unix, which now serves as the base of both Apple iOS and Android, made IPC designs easier, but they were non-standard.
By 2000, the industry decided that these software-to-software interfaces needed to become more open and standard. Such technical decision became the genesis of what we now refer to as an application programming interface or more commonly – API. Recognize that an API provides a standard interface through which two software programs, also referred to commonly as processes, can communicate, share messages, or managed shared memory.
More specifically, an API is an interface which makes software services available to workloads or applications for bidirectional communication and message sharing. APIs are also commonly used to share memory between different processes. An API is stateless in nature, and will commonly include all the information needed to complete a transaction, unlike a web form that may require multiple transactions for processes like user registration.
Figure 1. General API model
Unix Operating System IPC
Roughly half a century ago, researchers Ken Thomson and Dennis Ritchie of Bell Laboratories initiated a project to build a multitasking operating system for use inside AT&T. Despite such relatively modest original goals, the so-named Unix software and associated design philosophy that they produced have served as the technical base for virtually every successful commercial operating system since. Linux and Android are direct derivatives, whereas iOS and Windows are massively influenced by Unix.
An important design consideration for the Unix operating system involved the need to create an IPC mechanism that would allow for data sharing and message passing between computer programs. Thompson and Ritchie were influenced by many rapidly evolving technical concepts being designed at the time in the computer science community. This included the emergence of producer-consumer models, as well as new methods for distributed computing.
The Unix IPC approach can be viewed as an early attempt to address many of the issues now covered by APIs. Both are concerned with the need to modularize, standardize, and simplify the manner in which data or messages are shared between cooperating processes. The big difference, obviously, is that modern APIs benefit from the massive scale that comes with the Internet. Original Unix efforts were local and operating system-specific.
Contributing author: Matthew Keil, Director of Product Marketing, Cequence.