February 21st, 2014

Why an Open API is Like a Loaded Gun

APII 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 ]

February 18th, 2014

A World of Apps & APIs

Apps WorldApplications – and specifically mobile apps – occupy a key battleground for companies trying to woo customers, differentiate their products and drive growth. This is happening across many industries but banking provides a good example. Mobile applications that put banking services in the palm of your hand have become a much more important differentiator than interest rates, which were previously used to lure customers. A well-designed mobile app drives a more engaging experience for customers and this, in turn, drives customer acquisition and retention.

During the recent Apps World show in San Francisco, we saw some examples of this trend and the extraordinary growth right across the application ecosystem. Of course, behind every great app there’s usually a great API and my “State of the Union” address on APIs highlighted the hard work and success we’ve seen over the past few years. But it also served as a reflection on the key areas enterprises much consider as they accelerate innovation via APIs and engage customers in new ways.

Identity and security were recurring themes and we’ll certainly be hearing more about these issues in the coming months. With public awareness of mobile exploits and loss of personal information growing fast, mobile app security is going to dominate the thoughts not just of product managers everywhere but also those of lawmakers seeking to define stricter legislation to protect consumers.

In this context there’s an increasing need to double down on the fundamental requirement for strong-but-user-friendly identity and security functionality in mobile apps. For developers building apps against enterprise APIs, meeting this requirement can be extremely challenging. Thankfully, enterprises can simplify the situation by leveraging the advanced identity and security features of API Management platforms. Right now, app security is often a stumbling block but – by making some smart infrastructural decisions early on – enterprises can turn it into a serious differentiator.

January 31st, 2014

Would You Like a Library with That (API)?

LibraryIf you are professionally inclined – like I am – to read all about the business of APIs, you may have gotten the impression that APIs are going to take over everything and bring world peace.

Okay, I’m exaggerating but it is sometimes hard to remember that an API is really just a means to an end. That (business) end can vary. It might mean reaching more or different customers using mobile apps. It might mean integrating with partners. It might also mean giving access to services or data that provide enough value for them to be monetized. But in the end, I’m not using an API for the sake of using an API but because I want to use the services or data served by the API with the least amount of friction to myself because I – as a developer –  have a job to do.

Which brings me to my next point: When was the last time you looked at an API’s documentation and implemented it in a client app? If I need to integrate with an API in my Web app, I simply copy two lines of Javascript from the API provider page and cut and paste my API key into the <your_api_key_here> placeholder. Then I reload my Web app, which loads the Javascript library, which allows me to use the API. Or if I need to integrate with an API in the backend, I look for a pre-build component like a GEM (Ruby-on-Rails) or NPM (node.js) and add it to my loader file. Then I restart the backend, which loads the library, which allows me to use the API. Notice a pattern?

So here I am, using APIs via libraries/SDKs. In fact, I am not even sure when I last implemented a client using API documentation. In terms of priority, I only care if the service offered through the API meets my (business) needs – and then I use its library. And if it doesn’t have one, I might just move right along and look for the next one. (Remember: I have a job to do!)

For most developers out there in the real world, does consuming an API mean consuming an SDK that implements the API via a library? Should we talk about portable library design, efficient library loading (eager or lazy, async or sync) etc? Which platforms do I need to support to maximize my developer reach? What are the tradeoffs between offering (and having to support) a number of libraries versus just the API? Do dynamically-loaded libraries solve the API versioning challenge?

Reading about Evernote’s decision to use the Apache Thrift framework for its client API may help you formulate some potential answers to these questions.

In any case, none of this reduces the importance of providing a well-designed and documented API. Libraries and SDKs simply provide a convenient wrapper around an API and APIs are about removing friction. And client libraries are just another few steps in the march towards frictionless integration. (I still remember fondly the ease with which I was able to create client stubs and OSGI bundles from WSDL during the Web service days.) Nevertheless, we at Layer 7 – as an API Management company – will certainly be looking into how we can provide more support for client libraries in the future.

The preference for using client libraries rather than developing API clients becomes even more pronounced if we look at the Internet of Things.

Almost all the IoT integration vendors I have talked to consider supporting a large amount of client libraries for the myriad different IoT platforms to be one of their key differentiators in the market. Partly, this is driven by the need to optimize client stacks for resource-constrained platforms but it is also driven by the emergence of new binary and publish-subscribe protocols designed to better deal with IoT’s asynchronous communications patterns (see this blog post for a good overview).

While there has been quite some activity around API definition languages lately, I’m not aware of any attempt to provide a formal description language for asynchronous APIs of this type. Maybe this is an area where we will see some new ideas and innovation in the coming months.

In case you’re interested, I’ll be talking more about these trends as part of Layer 7’s upcoming API Academy Summits in London and New York.

January 30th, 2014

API Academy Summits

API Academy SummitsLast year, Mike Amundsen, Holger Reinhardt and I each traipsed around the world to bring API architecture guidance and advice to your home towns.  It was a lot of fun, we got to meet some great people and we had a chance to learn about the challenges that front-line API designers face. We also managed to earn a lot of air miles and give away a lot of t-shirts.

But this year, we wanted to top ourselves and do something bigger and bolder. So, instead of going out individually, Mike, Holger and I are getting together to dish out practical API design advice together in a series of API Academy Summits. I’m really excited about these events because we’ll have a chance to provide differing points of view and draw on our collective expertise to give you the best guidance possible. Our goal this year is to continue to go beyond the inspirational hype about why your business needs an API and go deeper, addressing the real challenges that people who actually have to implement API programs face in the real world.

In addition to the API Academy team, we are extremely pleased to have Forrester Research analyst Randy Heffner providing a keynote presentation. Randy has been a great source of API design information over the last year and if you’ve been reading his work, you’ll know he is all about providing great practical advice to API designers.

Our first Summit is taking place in London on February 6, closely followed by an event in New York city on February 13. These full-day events will include real API implementation stories from William Hill and L’Oreal as well as providing a mobile developer’s view of API design, courtesy of local London developer Niall Roche.

Last year, we were surprised to hear from API Academy workshop attendees that they wanted us to talk about Layer 7′s products. We want these to be vendor-neutral events but we’ve listened to the feedback and are trialing a short session introducing the Layer 7 API Gateway and Portal.  This session will be held at the end of the day and we promise not to lock the doors and force you to listen to the pitch!

So, if you have a chance to be in London on February 6 or New York on February 13, make sure you find time to join us for one of our API Academy Summits!

January 8th, 2014

APIs Past, Present & Future – API Predictions 2014

2014 Predictions Tech TalkThe beginning of a new year is a great time to reflect back on the year that was and look ahead to the year that will be. Because 2013 was such an impressive year for API technology, I thought now would be a great time to assemble a panel of API experts and talk about The Past, Present & Future of APIs.

This will be our first API Tech Talk of 2014 and it’ll be a great chance for our audience to interact with the panel, ask questions, make comments and ultimately learn and think about the future of APIs.

At Layer 7, we’re proud to have thought leaders and top industry talent when it comes to API design, API security, the API economy and IoT. On the panel will be members of our API Academy: VP Client Services Matt McLarty; Principal API Architect, North America Mike Amundsen; Principal API Architect, Europe Ronnie Mitra; Product Architect Holger Reinhardt; Chief Architect Francois Lascelles. They will be joined by Layer 7′s Director of Product Management, Ross Garret.

So, we’ve brought together experts from a design/usability perspective, a business perspective, an integration perspective and – of course – an API security and management perspective.

Our customers – and enterprises in general – realize they can transform their businesses through APIs by leveraging their digital assets and taking advantage of all-pervasive trends like mobile, BYOD and IoT. Mobile apps are an integral part of daily life for most of us and smartphone use has become commonplace in the enterprise.  Mobile app developers need APIs to build the exciting applications we all love to use. And as the recent Snapchat security breach teaches us, security is a very important – but sometimes undervalued – aspect of API architecture.

APIs are driving the future of business and there are a lot of considerations when talking about API Management. The API itself needs to be designed well, the security needs to be tight to protect user data, it needs to be developer-friendly and on we go.

While  2013 may very well have been the year of the API, 2014 could be the year APIs go mainstream. So, join us on January 15 at 9am Pacific Time for a live discussion of The Past, Present & Future of APIs. You can tweet your questions or comments directly to @layer7 or you can use the #layer7live hashtag. You can also email your questions directly to us (techtalk@layer7tech.com).

I’m really looking forward to hosting this discussion and think you’ll get a great deal out of the discussion. We value your input and look forward to hearing from you on Jan 15.