Five simple strategies for securing APIs
Proven tips for API security and management can help protect your apps and data.
I have the privilege of working with some pretty savvy folks when it comes to APIs and security. Scott Morrison, a distinguished engineer at CA, is one of those people. Over the past few years, we saw several incidents that could have been prevented with proper API management and security and the advice from someone with Scott’s experience. Here are Five Simple Strategies for Securing APIs, information Scott and the team at CA put together for our customers, and what might happen if you don’t adopt these strategies.
Validate all incoming data against a list of what’s considered permissible inputs into the system, and make it as restrictive as possible to harden that defense.
And if you don’t? A great example that’s been in the news quite a bit is Niantic, the creators of the Pokemon Go app. The app has a private API (meaning, not published for public consumption) that functions as the access point for the backend application that manages Pokemon Go user interaction and game algorithms.
Note that while Niantic never published an open API, they didn’t secure it sufficiently. That mistake allowed external developers to access and reverse-engineer that API to create apps that access even more information than was publicly visible in the app, ranging from individual value calculators that calculate a Pokemon’s strength, to nearby Pokemon scanners and bots. Other industrious developers in the wild built third-party apps like Pokevision and FastPokeMap. These other apps 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, Niantic changed their API so that these applications cannot access the server anymore. But in less than a week, developers again cracked the new API by reverse engineering the source code and finally gain access to the new interface.
Better validation of incoming API requests for realistic user inputs at realistic rates could have prevented the situation entirely, and has been implemented in recent updates.
Scott suggests that we should scan any input to an API gateway for common attack signatures, SQL injection, or script injection attacks – 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 Scott’s advice, they likely wouldn’t have had this vulnerability.
Secure your app from man in the middle (MITM) attacks. SSL is the way to do this. It provides integrity on all exchanges between a client and a server. This is a simple policy to implement, and there’s no downside to doing it.
A strong authentication and authorization system needs to be in place. For many situations, OAuth is the most appropriate API authorization technique.
And if you don’t? Tesla made the news recently. Rather than use OAuth, their Model S engineers chose to develop their own. By simply trapping the owner’s email address and password (done using multiple techniques described in this brief by George Reese), a bad actor could track every move the car makes as well as create economic woes by gaining control of functions and dramatically shortening battery life on trips potentially leaving the owner stranded on the side of the road with a very dead Model S. Reese and Morrison are on the same page on this issue: “OAuth is the proper authentication mechanism for user-to-system authentication”.
Do not invent your own. Yes, they’re out there, but they’re 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.
Do you have any API security successes or mistakes we can learn from? Please share them here the comments.