Securing APIs: A Look Ahead

• 

  Jakub Mikuláš
  

Earlier this year Neil Mansilla, former VP of Developer Relations at Runscope, presented the current trends, tools and platforms used for securing APIs. As a follow up to Neil’s presentation which is embedded below, Apiary’s Jakub Mikuláš takes a deeper look at the current state of API security.

It’s a Big, Scary World out There

We’ve all read the stories of hacked IoT devices, from cars and guns, down to a children’s doll. We’ve seen vulnerable protocols and implementations coming from even the largest vendors, where we’d normally expect a higher level of security assessment. We’ve witnessed both small and large attacks, and they’re not always as sophisticated as they should be. Quite often these attacks are exploiting weak API security: APIs without TLS, APIs using a single token for all devices, weak default credentials, and more. We laughed at the idea of adding a firewall to our refrigerator, but perhaps we shouldn’t have. Is current API security really that difficult?

The good news is that we’ve almost figured out securing server communication in the browser. TLS is becoming a standard even in small personal projects. We have new security policies and APIs in all major browsers. We can enforce and control security features simply by adding HTTP headers to server responses. These smaller building blocks add some serious security to the web. Can we say the same about the API landscape?

One thing is for sure: it’s very difficult to clearly understand the implications of choosing one protocol or scheme over another. While the core ideas and principles are usually well documented, frameworks and libraries rarely help with security tasks. One look at security.stackexchange.com can demonstrate how hard it is to understand these concepts. For example, what’s the top answer on Google for a cURL certificate mismatch? Add a few lines of code to disable the security check.

It takes teams of educated and dedicated people lots of time and resources to simply do security well enough. Those without the time or resources will ignore warnings and prompts that your tool produces if it slows them down or annoys them. Security and crypto are constantly moving targets which means this problem likely won’t get easier. With more and more IoT devices using APIs, the number of potential targets for attackers is skyrocketing; now more than ever you need to do security well.

History and experience show us that crypto and security can be described as exciting by only a fraction of people, and if it isn’t interesting and / or easy, people won’t care about it. We can keep inventing more intricate schemas or security protocols and yes, we need them, but that won’t make crypto inviting for everybody. Sadly, it just isn’t meant to be.

What we can do is improve the developer experience of implementing security. We can and should do a much better job explaining the drawbacks of disabling security features when developers are considering those options. We can develop libraries that require the highest security standards, standards that can’t simply be switched off.

One solution is to outsource your API security to someone whose core competency is security. We should think about strong API security as table stakes in API design. Outsourcing allows teams dedicated to security to do their jobs to my benefit, and allows me as an API developer and consumer to be able to trust any API I’m interacting with. That’s a win-win. I’ll note that this shouldn’t be something I pay extra for, it must be a standard option – strong security should be built into every API at every price point.

I look forward to a future where I can look at any API and check if their implementation of SAML, OAuth, Hawk or anything else is secure. A future where your API security schema is embedded in your API description as a first class citizen. Only then, with default strong and well documented security, will designing a secure API come naturally.