I talk a lot about APIs –sometimes I talk about testing them, sometimes I talk about designing them, and often I talk about marketing them. As I prepared for today’s discussion at API Strategy & Practice Conference I found myself combining all of that into one discussion for the Security & Testing track.
When we discuss marketing APIs, we often talk about developer outreach and making your API so easy to adopt that everyone wants to use it. The focus is on opportunity and innovation. What we seldom acknowledge is that this is the exact thing we guard against when we put together our security plans. When we wear our security hats, we worry about the kinds of innovative misbehavior that might occur.
In essence, marketing APIs and developing API security policies are really about the same thing – innovation.
On the marketing side, we want to encourage developers to innovate and use our APIs constructively. But from the security perspective, what really happens when we put an API out there into the public sector is that people often find innovative ways to use our APIs and/or the data destructively. It’s kind of the yin-yang of API innovation. Either way, it’s about trying to figure out what sort of creative, crazy, inventive things are people going to do with your data that you didn’t anticipate and that you didn’t think of yourself.
Security protocols are only part of the story – what we sometimes fail to remember is that people can walk right in your front door and still steal the silverware. Some of the most prominent examples in the news lately were victims of just that – hackers using the API as it was designed but finding that the design itself had holes they could exploit.
One example is Snapchat, whose API allowed for some creative misbehavior that resulted in people being able to connect phone numbers with all the users in the Snapchat ecosystem. Additionally, they could use the API to easily create thousands of bogus Snapchat users. Unfortunately for Snapchat, they ignored the original warnings from the hackers themselves and were eventually publicly embarrassed when the hackers went public.
(There’s a whole separate discussion to have about the legalities of hackers publishing exploit details publicly – something our legal system needs to catch up with if we’re going to protect both companies and their users.)
Likewise, Tinder also had a famous exploit where their API passed enough information about their users’ locations that clever developers could physically locate people. Even worse, they reacted quickly to the first report of this vulnerability… by releasing a fix that didn’t solve the problem. This vulnerability is one of the rare instances where people were theoretically put at physical risk, allowing a diabolical stalker/hacker to find unwitting Tinder users without their knowledge. Luckily, that didn’t happen… but it’s all about possibilities, right?
The Hacker Mindset
The key to preventing these vulnerabilities and security issues lies in having the right mindset. Typically, I think of both developers and operations people as having the mentality of builder, checker, and analyzer. When it comes to quality, they’ll generally ask questions like:
- Does this work the way I thought it would?
- If I inject an error into it, does it return the right message?
- If I put rate limits on my API are those honored?
- If I go above rate limits, am I blocked?
On the other hand, the tester mindset is closely aligned with how hackers think. Skilled hackers and testers approach a product (including your API) from a different vantage point – once they get past checking, they start testing:
- Now that I know the boundaries, how strong are the walls marking those boundaries?
- What can I do besides the obvious documented activities?
- What if I try this? Or this? Or this?
- Is there a way to go down a different path than the product obviously wants me take?
They do not feel obligated to use your API in the way you intended. They’re the ones who are taking all of that critical thinking, those “out of the box” ideas, and really testing the limits of the data that you’re delivering. They’re trying to poke holes and take advantage of that seemingly innocuous vulnerability in your API.
A new approach to testing is imperative in the new world of software development. We’re already moving away from the waterfall, process-heavy, metrics-heavy testing of the past. But we still need to think about new strategies to keep up with the API boom and the Internet of Things, both of which are changing the landscape of technology in a major way.
So, how can you find the vulnerabilities your test scripts can’t uncover?
If you really want to get the ultimate coverage when testing your API, embrace the hacker mindset and bring hackers onto your team. Work with them, rather than against them. Listen to them and learn how they think about that data you’re delivering. If you bring them into your process early enough, before you’ve delivered your API to market, you can deploy with a greater confidence.
Another strategy is to put the“hack” back into hackathons. Sure, we’ve been talking about the benefits of hosting hackathons for years. But the hackathons that most organizations set up are maker events. Those hackathons focus on getting as many developers as possible building as many apps as possible, using your API. Exactly the thing security folks worry about.
So, what if we hosted hackathons where we really encourage hackers to get creative in malicious ways? Find the vulnerabilities before you go to market by using the same strategies you use when marketing your API.
We’ve got to start realizing that security is not just about protocols, gateways, and rate limits. We need to embrace the innovative misbehavior of hackers as one of the best ways to test our APIs and the data we deliver.