What airports can teach us about API security

Frequent travel through airports across the United States has influenced my views on security best practices for application programming interfaces. U.S. airport security has evolved into a federated model of collaboration between state authorities, airlines and the Transportation Security Administration incorporating terminal concourse design constraints, a multiplicity of access control mechanisms and constant monitoring.

At each airport, the TSA grants me access to the concourse after validating my state-issued driver's license and airline-issued boarding pass and after my belongings and I have been screened by sniffer dogs and scanning machines. Inside, the concourse is restricted by design to the minimum set of amenities, and I am also monitored by TSA officials for high-risk behavior at my gate and throughout the duration of my flight by federal air marshals.

The airport model can teach us a lot about modern API security strategy. For example, APIs can make access control decisions by challenging the API consumer to present multiple trustworthy identity and access tokens. Like the concourse design constraints, each API can be designed to do the minimum necessary to satisfy the requirements of the business channel through which the user is engaging. And every API call can be constantly monitored to identify unusual behavior. 

The API security challenge

Confidentiality, integrity and availability collectively form the goal of IT security strategy. The aim is to hide private information from unauthorized users, prevent its unauthorized manipulation and ensure access to it when needed by authorized users. These objectives were easier met when application architectures were monolithic and users could be given application-specific roles based on their organizational group memberships. Every component within the application was designed with an inherent understanding of all the user roles and their access permissions. 

However, composite applications today are pieced together through APIs that are consumed by user interfaces commonly referred to as apps. The APIs are typically reused for multiple purposes, so they are not bound to any one application. This makes access control more difficult because multi-use APIs cannot “know” beforehand who all the app users are, which apps and other APIs will consume them nor which app-specific roles should restrict their execution.

Furthermore, apps increasingly consist of multiple APIs distributed across sometimes open networks, leaving them isolated from the very context of their consumption. This distributed landscape changes the fundamental nature of application security, allowing potential attackers to bypass the consuming apps in their attempt to invoke the APIs. The only solution is for each API to shoulder the weight of security as if each were its own application. 

Risk mitigation through minimalist API design

The most fundamental API security question is “What does this API do?” Not everything an API does is appropriate for consumption by any particular app. Apps consume APIs to realize the functionalities that they offer. One click of a button on an app can trigger a chain of API calls to satisfy a user request. Though multiple APIs are needed to fulfill a request, they should all be abstracted under a single experience API that acts as a gateway to all the others. This experience API should be “minimalist” -- designed to do only what is needed by the app and nothing more. 

The multiple APIs needed to satisfy app requests can be divided into two categories:  

Process APIs cater to business process automation through which agencies deliver services to stakeholders and answer queries about the status of previously requested services. 

System APIs answer queries for information like what services are available. They are also responsible for the data persistence necessary for business process automation, but they are agnostic to any particular business process, making them reusable across multiple processes and business channels. Process APIs realize their work through orchestration and choreography of the system APIs and are reusable across multiple business channels.

In addition to the experience APIs, minimalist API design can apply to the process and system APIs too. Each API should be discrete in its responsibility. A process API should kick off only one business process. A system API should cater to only one type of information. This discreteness of responsibility also facilitates reuse because it makes building blocks of the system and process APIs. Thus they can be composed and recomposed for multiple different apps. The building block aspect also allows architects to deliberately exclude unnecessary system or process APIs from experience API compositions because their capabilities are deemed inappropriate to the business channel for which the app was built.

Risk mitigation through multiple access control and monitoring mechanisms

Minimalist API design simplifies runtime concerns around access control and monitoring, given the attack surface of each API is reduced to the minimum necessary from a business perspective. Nevertheless, each API should still check incoming calls and decide whether or not to honor the call.

API security is ultimately about guaranteeing that API calls are driven by authenticated users, using authenticated apps -- and that information about the users can determine their authorization. Employing the assurance practices of the National Institute of Standards and Technology's Digital Identity Guidelines will give appropriate levels of confidence based on the risk associated with each API.

The NIST Federation and Assertions publication provides clarity on how APIs distributed across an application network can make authorization decisions. In a federated system of trust that the application network requires, assertions about authenticated users, apps and APIs can be issued by a centralized identity provider and validated by each API for access control. This is similar to the way state-issued REAL IDs and airline-issued boarding passes can be validated for access control throughout the network of TSA checkpoints across the country. 

In addition, monitoring mechanisms can mitigate the risk of access control mechanisms failing to address stolen keys. For example, user behavior anomaly detection by machine learning analysis of many invocations can indicate whether API access control has been compromised, much like TSA person-of-interest monitoring. This correlates to suspect API activity being easily discovered by machine learning analysis of many invocations. For example, in 2018, 30 million users had personal information exposed after Facebook API access tokens were stolen. That breach was discovered when an unusual spike of activity was observed by monitoring of API calls.

Conclusion

According to Gartner, API abuses will be the most-frequent attack vector resulting in data breaches by 2022, some of which will inevitably impact government organizations. As Rohit Chopra, commissioner for the Federal Trade Commission, told the New York Times: "Breaches don’t just violate our privacy. They create enormous risks for our economy and national security." 

API security conversations often emphasize using single access control mechanisms like OAuth. However, multiple mechanisms should be employed, much like securing a door with multiple locks. Access control is only half the story. Organizations should minimize API attack surfaces through restrictive design and ensure the quick discovery of API breaches through machine-learning based monitoring.