The benefits of a well-designed, well-implemented, easily integated API are well known: happier developers, higher usage and, hopefully, greater profit as a result. While many high-level best practices for developing a great API have been established, a failure to pay close attention to small details, such as parameter defaults, can create big headaches.
DigitalOcean, a cloud hosting upstart that was one of the fastest-growing hosting companies in the world this past year, learned that the hard way recently when customers discovered a security issue produced by a default parameter setting in its API.
Like most cloud hosting companies, DigitalOcean offers virtualized servers on hardware that is shared by multiple customers. When customers delete virtual servers (which DigitalOcean dubs "droplets"), they have the option to "scrub" their data to ensure that it is deleted entirely from disk. If this is not done, data could remain and be accessed by other customers that later create a droplet on the same physical server.
On Dec. 29, a DigitalOcean customer observed that a "scrub_data" parameter was, by default, set to false for droplet deletion requests initiated through the DigitalOcean API destroy endpoint. The customer posted an issue about the API parameter on GitHub and, worse, confirmed he was able to retrieve another customer's data from a previously deleted droplet that had ostensibly been destroyed without the "scrub_data" parameter set to true.
A dangerous default
Needless to say, the fact that a customer was able to access another customer's data sparked an immediate firestorm. A DigitalOcean employee responded, pointing out that "In both our API documentation, and our control panel, we note that you must either pass a flag or check the box to [securely] delete the data. As far as I can tell, the flag is currently [functioning] correctly."
But that didn't sit well with some users of the company's API. One user responded, "The hubbub is most likely that the default behavior is to leak data and that users of software that consume the [DigitalOcean] API are several layers removed from the flag that would protect them, so [DigitalOcean] being proactive and defaulting it to True would be a Good Thing™." On Hacker News, another user suggested, " 'Oh, there's an option for that' to stop default dangerous behavior should not be excusable."
When confronted with the suggestion that his disclosure was potentially irresponsible, the user who brought this issue to light and confirmed the ability to access another customer's data defended his action, stating "This is simply a case of DigitalOcean using dark patterns and user-hostile defaults."
Obviously, DigitalOcean's poor choice of a default for such an important parameter provides a powerful example of why it pays to pay close attention to API parameters and their defaults.
It also highlights the importance of interface consistency. A growing number of companies allow customers to interact with their services through multiple interfaces. In DigitalOcean's case, customers can create, manage and delete the droplets API as well as a web-based portal. The portal, unlike the API, had a "scrub" option set to true by default, a discrepancy that may have led customers using both interfaces to make a faulty assumption. After all, if a parameter has a particular default in a web interface, one might reasonably assume that the default is the same in other interfaces.
In the end, DigitalOcean took prompt action to address the concerns its API had created. Just a day after its API design decisions had come under fire, the company published a post on its blog apologizing for what it called a "mistake" and announced that it had changed its default for the "scrub_data" parameter to true.
In addition, the company made a commitment to be more careful about defaults going forward. "We should never have updated the default behavior to an insecure method. Going forward we will always ensure that the defaults remain sane, and that the customer’s concerns and their security are highest priority," the blog post stated.
Companies building new APIs would be wise to do the same, and DigitalOcean's flub reminds companies with existing APIs that it's never a bad idea to revisit API design decisions after the fact to ensure that they live up to reasonable customer expectations.