This week, Axway released our plug-in for the Smartbear Ready!API testing tool. The plug-in provides integration between Ready!API and Axway's API Management solution.
As part of the launch, we're also running a joint webinar on September 10th, where we will discuss the two sides of API Security - testing and protection. The webinar includes a demonstration of API Security in action: both the testing (Smartbear Ready!API Secure) and the protection (Axway API Gateway). We'rerunning the webinar twice on the day, to accommodate different timezones.
Here are some of my thoughts before the webinar:
Is API Security new?
The API Economy has taken off in recent years, and it is tempting to think that API Security is a new thing. But it has a long history. Security of SOAP APIs has, of course, an infamous history involving many WS-* standards (some of us wrote whole books on these :) ). SOAP/XML attacks like the XML Bomb keep coming back to haunt developers. However, REST has a longer history than people realize. Way back in 2003, Jeff Barr in Amazon, famously pointed out that only 15% of Amazon Web Services traffic is SOAP based, and [here comes the pun] the rest is REST. Both types of APIs had to be secured.
At the RSA Conference in 2006 (almost 10 years ago, yikes!), I gave a talk on REST Security, when much of the discussion was about "pure" versus "practical" REST. Mobile then became a driving factor in how APIs are used, creating facts-on-the-ground that moved us on from much of the theoretical discussion.
How important is API Security?
API Security is very important. Everyday users may think "I never call APIs, only developers do that", but the reality is that mobile apps and IoT devices call APIs regularly. And this is where API security issues manifest. Let's look at what two researchers have found with API Security for mobile and IoT:
On the mobile front, Troy Hunt's influential "Hack Your API First" article and training makes it clear that much of mobile security is actually really API Security. As Troy explains, if you want to probe an app's vulnerabilities, a good way to start is to see how it calls APIs. If you have your app use a proxy (simply by changing your phone's connection settings), and then by running a tool like Fiddler, you can often see very obvious security vulnerabilities.
On the IoT front, Randy Westergren has shown how IoT devices can call APIs in insecure ways. These APIs calls become the vulnerability. In this case, a security layer was needed in front of the APIs to protect them. An API Gateway fits the bill. My colleague Rob Meyer has talked about how Just-In-Time principles can be applied to DevOps testing, remarking that "Testing is the Andon cord of DevOps" (don't know what "Andon cord" is? I highly recommend checking the article).
So, on the API Security webinar on September 10, I'm looking forward to a great discussion about the two sides of API Security - testing and probing for vulnerabilities (the "sword") and protection (the "shield"). See you there!