Serg Nvns - Fotolia
APIs are an essential technology that unfortunately presents some design and security problems for developers. At the beginning of the year, Steve Willmott, CEO of API management platform 3scale, made 10 predictions about what would happen with APIs in 2015. We talked with him about some of his predictions.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
In part two of this two-part Q&A, we talked with Willmott about API security, including attacks, malware and advice for API designers.
One issue with making your APIs public is security. Do you see attacks, particularly on APIs, increasing? How do you see that playing out in terms of API security?
Steve Willmott: This is one prediction that is almost true already. There have been a number of things that have happened already this year. There was a company called Moonpig in the UK, which was a printing company that had an API, and they accidently exposed all of their user data via the API. That happened the first week of January. WhatsApp and SnapChat both recently made some significant changes to their APIs because of security threats.
I think that there will be more. I do not think it will make APIs go away, but it makes the level of caution required rise. There have not been that many attacks on APIs to date, but of course they are very attractive targets, because once you get in, you can potentially get a lot of information out of it much more easily than you would if you broke into a website.
We will definitely see, unfortunately, more attacks. But hopefully we'll see improvements in security over time as well. It is high risk, high reward in some sense, having this out there, but the reality is for mobile and pretty much any application, you need APIs. Rather than taking them away, it is just a question of figuring out how to protect them adequately. The technology out there needs to be applied.
The breaches that have happened this year so far are mostly down to just not paying attention on the part of whoever is running the API. That is unfortunately what happens all over the Web, and it is going to happen for APIs as well. People mainly not securing them in the way they should.
If you are giving your API to people to create applications with, does it also give them the opportunity to create malware?
Willmott: Potentially, it does. There are definitely things to think about. One use of an API is to allow third parties to write apps for your platform. Facebook allows that. You can be a Facebook developer and write apps that actually connect to the Facebook data stream, and so Facebook is giving you a certain amount of rights. If you are doing that with an API, the best practice -- which we recommend and support through our product -- is to only allow certified developers to do that. You would have people sign up and at least validate who they are. Have them run a test first so you can validate what they are doing, and only then give them permissions. If anything ever goes wrong, you can revoke the permissions of that app.
Literally, you are, to some extent, lending your brand to some of these third-party developers, and some of them might be bad actors. You need to be able to switch them off if they do that, and also try to detect those folks upfront. Once something goes into the Android store or something, and it is an app that works with your platform, then a user in the field will assume that it is safe, so it is kind of important to have process around that.
What is your advice to API designers? Are there any tips you could give them, any 'dos or don'ts' about security?
Willmott: I think the No. 1 thing that we see that creates security attack factors is people try to write their own authentication layers. If you have the OAuth button app, that is probably the most common security protocol that you would use to secure an API that is for Web or mobile consumption. It is unfortunately pretty complicated. It is very easy to make a mistake somewhere and implement it wrongly.
In addition, there are open source libraries out there. We also provide a service, but there are plenty of them out there. Reusing an open source library or something like that, rather than rolling your own is the best way not to have a hole there, and that is probably the most common thing. Whichever protocol you are using, go look for open source libraries to start with, rather than rolling your own clients and servers from scratch. Just one error somewhere may expose the whole thing.
Editor's Note: This Q&A was edited for grammar and style.
Ensure your cloud API is secure
How to use the Enterprise Security API
Dig Deeper on Securing services