Five Simple Strategies for Securing Your APIs, Revisited

I’ve been updating assets recently, and had scheduled a refresh of Scott Morrison’s eBook, Five Simple Strategies for Securing APIs.  As I read through it, I found myself nodding my head over and over – Scott was just spot on.  Each of his strategy points have been proven to be sound – and as importantly, each has been proven, if ignored, to have a negative impact on the implementation.  Let’s go through them briefly and take a look.

Strategy 1:  Validate Parameters

What Scott is pointing out is that if you validate all incoming data against a list of what’s considered permissible inputs into the system, you have a very effective defense.  He further states that this should be as restrictive as possible to harden that defense.

And if you don’t?  Certainly a great example that’s been in the news quite a bit is Niantec, the creators of the Pokemon Go app.  The app has a Private API (meaning, not published for utilization) that functions as the access point of all programs in accessing the database and programming algorithm of Pokemon Go. Note that while Niantec never published an open API…but they didn’t secure it…and this access point allowed external developers to reverse-engineer that API to create apps that access that database, ranging from an Individual Value calculator, to nearby Pokemon scanners and bots.  Other industrious developers out in the wild built 3rd party apps like Pokevision and FastPokeMap.   These other apps still used Niantic servers as part of the immersive process.  Due to the volume of third party apps accessing the servers of Niantic, and the processing power necessary to address the requests, down times and server side issues occurred. To address this, in early October of 2016 Niantic changed their API so that these applications cannot access the server anymore. But in less than a week, developers again cracked the new (unsecured) API by reverse engineering the source codes and finally gain access to the new API.

A validation of what data is coming in, from what app, would have prevented this situation completely – reinforcing Scott’s Strategy #1.

Strategy 2:  Apply Explicit Threat Detection

What Scott is suggesting is that any input to an API gateway should be scanned for common attack signatures, SQL injection, or script injection attacks.  This just makes common sense, especially if customer data is involved.

And if you don’t?  McAfee – a security company, recently was hit with a script injection attack on their anti-malware solution, VirusScan for Linux.  While they’ve patched the software, by applying Strategy #2, they likely wouldn’t have had this vulnerability.

Strategy 3:  Turn on SSL Everywhere

Scott is a big believer in the value of securing your app from man in the middle (MITM) attacks – SSL is the way to do this – as it provides integrity on all exchanges between a client and a server.  This is a simple policy to implement, and there’s no reason not to do it.

Both Facebook and Instagram have recently had issues with MITM exposure – in both of their cases, simply enforcing SSL would have resolved that exposure, validating Strategy #3.

Strategy 4:  Apply Rigorous Authentication and Authorization

What Scott is driving at is that a strong authentication and authorization system needs to be in place – and that for many situations, OAuth is the most appropriate API authorization technique.

Tesla made the news recently – rather than use OAuth, their Model S engineers chose to develop their own (something Scott specifically advises against in the eBook).  Through simply trapping the owners email address and password (gained through multiple techniques described in this brief by George Reese), an attacker could be used to track every move the car makes (as well as create economic woes….shortening battery life on trips dramatically through performing various functions that they’ve gained access to – potentially leaving the owner stranded on the side of the road with a very dead Model S).  And, George reiterates Scott’s Strategy #4 in his brief: “OAuth is the proper authentication mechanism for user-to-system authentication”.

Strategy 5:  Use Proven Solutions

This is a reinforcement of Strategy #4 – do not invent your own.  While Scott has seen this multiple times, it’s never as solid as a hardened API Management solution built from the ground up to provide the security policies to protect your business and its data. 

If an organization implements these five strategies as part of an API security architecture, they have taken many of the steps necessary to keep their data secure.  I highly recommend taking some time to read Scott’s eBook, Five Simple Strategies for Securing APIs.  You’ll be glad you did.

Recent Posts