I recently participated in another of the excellent TechViews tweetchats, hosted by my friends from CA Technologies using the handle @TrendsInTech, on the topic, ‘The Risks & Rewards of API Development’. It was a great chat and you can check the full chat summary at Storify.
Among other things, I was at one point inspired to tweet that “an open API is a bit like a loaded gun: Harmless ‘per se,’ but lethal in the wrong hands.” Soon after, I received an email from someone reading the chat, asking for clarification, so I thought I would jot down my thoughts here.
My intent was to say that that, like a loaded gun, an open API is not necessarily bad per se but it certainly can be very dangerous if not handled correctly. It depends on what it does, who uses it, how they use it, what they intend to do and what they actually do (even accidentally). An open API with wide-open access, no throttling, no identity controls etc. is fine if it is used as intended. However, if it is used by a malicious actor, with malicious intent, and/or for a malicious outcome, then it can be very dangerous indeed.
One example of what can happen when an API is not protected, controlled and monitored happened recently with the Snapchat API.
Snapchat had an accessible (though not openly published) API that allowed any mobile Snapchat app user to provide a cellphone number and get back Snapchat profile details of the user with that phone number. This was designed to help users find their friends – innocuous enough on the surface, though clearly not informed by historical breaches caused by the same functionality.
As designed, this API was intended to accept a small number of cellphone numbers in each call, to return just a handful of known profiles. However, it was not well secured or properly throttled, leading to some dangerous unintended consequences. A small group of Australian security researchers known as Gibson Security figured out they could use the API programmatically to hammer the Snapchat servers with tens of thousands of phone numbers per request – some valid, many not. Pumping up to 75,000 requests into the API at a time ultimately resulted in Snapchat divulging profile details to 4.6 million users.
In this respect, the Snapchat API was like a loaded gun just lying around. Only authorized users were meant to have access to it but there were no safeguards to make sure of this. Like a loaded gun, the API was harmless as long as the trained and registered owner (i.e. the Snapchat app) used it as intended. Yet it was still just lying around where anyone could get to it and when an unauthorized user eventually did access it, with intent to use it maliciously, there was no protection at all.
It wasn’t that the API was inherently malicious. Like a gun, it could be used for good or bad purposes but like a gun, handled by a malicious actor without protections, it became a harmful weapon.
From a customer perspective, this is unacceptable. Witness the outrage from the Snapchat user community when this was discovered (although you could be forgiven for thinking it really didn’t matter in the end). From a governance, audit, security and compliance perspective, no business should ever consider opening up their APIs to any users — internal or external — without adequate controls, such as identity and access management, threat protection, error detection, usage tracking and rate limiting.
It is not just Murphy who knew that anything that can go wrong will go wrong; security analysts live and breathe this every day. You cannot assume an open API will not be abused; indeed, you must assume the very opposite. Even if you don’t publish details for an open API, you cannot assume no-one will find it; there is no such thing as security through obscurity.
API protection is as important to your systems and data as a safety, a holster, a trigger lock or a gun safe is to a loaded weapon. Fortunately, CA Technologies has invested in solutions that can help resolve these issues. The CA Layer 7 API Security & Management Suite “provides enterprises with a comprehensive set of solutions that externalize APIs in a secure, reliable and manageable way.”
So, next time you are working on an open API, make sure you drop by CA.com first. After all, you wouldn’t want to be the programmer that left a loaded gun around, would you?
[This post first appeared on the CA Security Management blog ]