Perhaps proving just how difficult API security can be, even for the biggest of API providers whose bench is deep enough to leave no stone unturned, it appears as though Instagram's API is still responding to certain queries with images that are supposed to be private and therefore excluded from the results. News of the vulnerability comes after the social photosharing subsidiary of Facebook announced that it fixed the problem.
According to Quartz (qz.com; the media group that did the testing), Instagram buttoned up some, but not all of the original vulnerability. As a result, API calls that query Instagram by hashtag were returning private photos that should not have been returned, including "a selfie of a women in her underwear and a picture of someone holding marijuana."
API security vulnerabilities have proven to be a vexing problem for some of the biggest online brands over the last 12 months and are showing no signs of abatement as we head into 2015. Starting in Spring 2014 and leading into the summer, hackers hijacked an untold number of Pinterest accounts and posted hundreds if not thousands of malware-related links to Twitter. The transgression had the distinct markings of a mass OAuth token heist (which would have required unauthorized access to Pinterest's databases). But Pinterest refused to disclose any details relating to the attack.
Then, later in 2014, in what later became known as "The Fappening," hackers gained access to a cache of compromising and thought-to-be-private photos that were stored in various celebrities' iCloud accounts. The hackers appeared to have employed a brute force attack on a private Apple API that had no rate-limiting on it. Apple rate-limited the API as soon as the vulnerability was made public but like Pinterest, also failed to disclose the exact details of the breach.
Before the year was out, yet another photosharing service -- this time SnapChat -- fell prey to the unauthorized use of its APIs in a hack that became known as "The Snappening." What made the Snappening and Fappening so similar is that the APIs that were hacked were supposedly private APIs. But as ProgrammableWeb pointed out in its recent analysis (see How Hackers Crack Supposedly Secure And Private APIs), most private APIs are neither secure, nor truly private.
Then, as a reminder that 2015 is very likely to be business as usual, a developer revealed how, through its API, the popular U.K.-based personalized greeting card, mug, T-shirt site Moonpig was exposing information that was supposedly private to more than 3 million of its users. Moonpig had been privately warned of the vulnerability in August 2013 and did nothing about it until the vulnerability was made public at the end of 2014.
And now Instagram.
Without more information, it's difficult to determine the root cause Instagram's problem. Vulnerabilities of this type are not unusual and can point to a weakness in the API provider's implementation of access control. In typical enterprise computing environments, there's an authentication layer that authenticates who you are, and an access control layer that controls what assets you have access to, based on who you are.
In Instagram's case, the use-case appears to be one whereby Quartz legitimately obtained an API key from Instagram for the purposes of developing an application that consumes Instagram's API. When Quartz's application attempts to access the Instragram API, it must also furnish that API key as a form of application authentication, which in turn (through properly configured access control), should govern what assets the application has access to.
But supposing Quartz offered its newly developed application to users through an app store, those users would also have to be authenticated by Instagram as legitimate users of its service (the role of OAuth). Once an Instagram account holder authenticates him or herself through a third-party application like Quartz's, Instagram's access control systems should govern what assets that user has access to. For example, User X, based on who she is, can see all of her own private photos. But User X cannot see User Y's private photos unless User Y authorizes her for that level of access.
In Instagram's case with Quartz's app, where certain queries worked and other ones were blocked, one possibility is that the access control is being managed in the source code behind the API rather than as a part of a larger, robust access control configuration where access to private assets is dictated by who you are rather than what your query was (or was not). But that's just one possibility. There are all sorts of plausible scenarios and the point of this analysis is not to suss out the actual problem in Instagram's API infrastructure, but rather to show how complicated API security can be, even for a big company like Instagram.