This is eighth part of ProgrammableWeb’s series on Understanding the Realities of API Security. It is based on the testimony offered by ProgrammableWeb’s editor-in-chief David Berlind to the ONC’s API Security and Privacy Task Force. In the previous part -- Part 6 -- Berlind answers the following question posed by the ONC: What Are The Perceived and Actual API Security and Privacy Concerns?
In my humble opinion, the risks can be mitigated in a variety of ways. First, it is important to recognize that API providers generally take one of two approaches when it comes to providing their APIs; they either build the majority of their bespoke API infrastructure from scratch or they rely on canned API management and security solutions that pack many of the better known API security approaches behind the click of a mouse. However, as said earlier, the API attacks that we have observed in the real world are sophisticated, multi-dimensional attacks that involve more than the API infrastructure itself and, as with most sectors of tech, even the most advanced solutions are sometimes out of step with the most freshly baked security standards.
As such, the proliferation of a constantly evolving set of best practices --- an API security checklist or cookbook if you will --- for not just securing APIs, but their adjacencies as well, can inform the key stakeholders on how to maintain the best possible API security. For example, in the aforementioned incident where the unauthorized penetration of a Github source code repository was one link in the chain that led to the ultimate attack, requiring two-factor authentication to access that source code repository would have stopped the hackers dead in their tracks.
When I say constantly evolving, an example of this would be how this month’s white-hat discovery of an API-related exploit of the user ID/password management service LastPass would immediately inform the checklist.
If such a cookbook were based on both theoretical and real-world incidents (in real time), the architects of both bespoke and canned API management solutions would have a comprehensive resource to turn to in order for their implementations to cover a majority of the beachfront.
Additionally, the same checklist could be used as the basis of some sort “Good Housekeeping Seal of Approval” whereby the checklist would serve as the basis for independently conducted audits in order to earn the seal.
In researching the majority of the real-world API attacks that have taken place over the last two years, I have begun to formulate such a checklist while contemplating a seal of approval and what role ProgrammableWeb could play in maintaining such a program. But so far, it’s nothing more than an idea.
Another way to protect APIs is to make sure a majority of their interactions are taking place behind a firewall (as in making them server to server interactions vs. client to server). But this is an architectural approach that doesn’t easily apply to a great many situations.
Today, the most favored approach to closing the exposure of API secrets when a mobile application is involved is known as “certificate pinning.” It is a technique that not only breaks the tenants of the DNS (which is partially responsible for making the Internet operate the way it does), it significantly erodes the aforementioned API benefit of loose coupling.
Finally, and this is true for every industry, (1) something must be done to ensure that white-hat activity does not end in criminal prosecution and (2) it is beholden upon the various industries and the companies in them to establish bug bounty and disclosure programs that encourage the type of white-hat research that ultimately results in a much better-protected infrastructure.
In the next part -- Part 9 -- of ProgrammableWeb’s series on Understanding the Realities of API Security, ProgrammableWeb editor in chief David Berlind answers the following question posed by the ONC: Could Third Party Certification Authorities Play a Role In API Security?