Ninety years ago KitchenAid released their first countertop mixer, which weighed in at about 69 pounds. More interestingly, the mixer also had a special socket that allowed users to attach assorted add-ons for new functionality such as slicers, shredders and meat grinders. Today this sort of extensibility of countertop-appliances is old hat for KitchenAid and their competitors. The interesting thing about this socket is that it has not changed in size or shape since the very first version was released. As a result, you can buy a brand new attachment, say the pasta rollers and it will work in every single version of every KitchenAid stand mixer ever made. Talk about backward compatibility!
Just like with mixers, people want to be able to extend the functionality of their software. There are a number of ways to do this: writing plug-ins, extensions, modules, etc. The easiest way to do this is usually via an API. You can think of APIs the sockets that allow you to attach all those lovely attachments that you can buy at places like Williams-Sonoma.
The cool thing thing about APIs is that they generally give you a lot more power and a lot more access to the application and its underlying data. This means that you can manipulate the program and data in ways which can be difficult or very in efficient from the front end. Tasks that would take many steps or require much repetition can be automated and in many cases be sped up by orders of magnitude as well.
Often APIs also give you access to certain functions that are just plain unavailable otherwise. This is where things can get dicey. Many APIs limit what you can do, how you can do it and enforce all sorts of security rules. However, APIs are often granted much more trust to the underlying code and data than users are, and in fact, many large applications grant APIs administrative access by default. This is not necessarily a bad thing until you realize two things: API services from applications don’t always require authentication by default and in most organizations there is little to no firewalling or access control in place.
To get back to the KitchenAid, there is nothing to stop you from building your own attachments and and certainly there is nothing to keep you from installing one that is very dangerous, say having lots of sharp blades with no finger guards. And if you have the kind of kid (or spouse or parent) who can’t help but tinker with dangerous things, you better not let them near that mixer with a socket set and an acetylene torch.
On the application side, what this means is that in spite of having SSL in place to prevent snooping and access control groups to limit data access, it won’t matter one whit if you’ve left backdoor access via the API wide open. An unhappy employee with a few free hours at his or her disposal can suck your database dry and you’ll never know it, since they’ll look just like any other B2B type calls.
So what do you do? When faced with this scenario you have three options: limit access to the API services using firewalls, access lists or other segmentation technologies; force authentication (preferably bidirectionally); and monitor the data flows around those portions of the network to see when data starts going places it shouldn’t.
David Mortman is a contributing analyst at Securosis.
*KitchenAid mixer image via Flickr user Achichi‘s photostream, Creative Commons
