Empirical Evaluation of API Usability and Security

Today's computer systems often contain millions of lines of code and are constructed by integrating components, many of which are authored by various third parties. Application Programming Interfaces (APIs) are the glue that connects these software components. While the SEI and others have placed significant emphasis on developing secure coding practices, there has not been an equal emphasis placed on APIs. This blog post describes our recent research that aims to provide specific guidance to API designers to help them deal with the security issues regarding development of APIs.

Overview of API Security Vulnerabilities

APIs have had a long history of undermining the security of software systems. The C-string library was developed in the 1970s, and is still a major source of security issues. More recently, many webpages began to feature a button that allows users to log on using their Facebook credentials. Such webpages must use an API written by Facebook. Similarly, if the webpage uses another provider for authentication credentials, that provider's API has to be used. Unfortunately, researchers found that although these APIs were technically correct, they were very hard to use securely. Indeed, the research showed most web sites used them incorrectly, and users could have their Facebook or other credentials stolen (these problems were subsequently fixed).

This example illustrates that, ultimately, the cause of cybersecurity failures is flawed code written by programmers. After all, programmers are people too, and people make mistakes. It is not good enough for an API to be technically correct, it has to also be usable by other programmers, or failures will result.

Foundations of Our Work

Although it makes sense to design APIs to make them easy for programmers to use, there has been little work on how to do so, and common sense has proven unreliable. To our knowledge, we are the first researchers to study the security aspects of API usability.

Brad Myers, a professor at CMU's School of Computer Science, is a co-principal investigator on the project along with his doctoral student, Michael Coblenz. We are also collaborating with Jonathan Aldrich, another professor at CMU's School of Computer Science, and Joshua Sunshine, a systems scientist at CMU's Institute for Software Research, and Forrest Shull at SEI.

Our research concentrates on the usability and security of non-security-related APIs because we are interested in security issues that occur when programmers are focused on functionality, not security. Our research makes little distinction between APIs, software development kits, and language features. For example, concurrency is built into Java, but it is thought of as a library in C (although compiler-writers disagree with this). Also, C++'s const and Java's final have different semantics.

Ultimately, our research has three goals:

• Provide actionable and specific guidance to API designers about the impact of API design decisions on security and the interaction between usability and security.
• Provide guidance to language designers about language features that affect the ability of API designers to express important properties.
• Provide accepted methodology for research in this area.

The first stage of our research focused on interviewing and surveying professional programmers, as well as structured interviews with key API designers to identify security-related issues. The second phase of our work focused on designing and building prototype tools that allow designers to improve the usability and security of the APIs they build. The third phase of our work is conducting controlled experiments with students and programmers to validate and measure the results of our attempts to improve API usability and security.

Control of State and Mutability

One of the fundamental design decisions made by an API designer is how state is to be managed and controlled. For example, both the security and functional programming language communities highly recommend designing immutable objects, which are objects whose state cannot be changed after creation.

The following items exemplify this guidance:

• Oracle security guidelines stress that maximum reliance on immutable objects is a sound strategy for creating simple, reliable code.
• Java security guidelines stress that additional work is required for mutable objects to protect against vulnerabilities.
• Finally, mutability, which is closely related to TOCTOU attacks, involves changing the state of an object after permissions are checked but before sensitive operations are performed. Since immutable objects cannot have their state changed, using them prevents TOCTOU attacks.

Prior Work

Prior work done by one of Dr. Myers's former students, Jeffrey Stylos, raised interesting research questions. Stylos and Steven Clarke of Microsoft, in their paper Usability Implications of Requiring Parameters in Objects, studied the usability of two different ways of constructing objects in APIs. If you have an object "FooClass" that requires two parameters to be used successfully, there are two basic choices of how to construct the object, as shown in the following code:

Two fundamental patterns for object constructors:

1. Required-constructor: