With the explosion of social media, cloud computing and mobile devices, 2013 was the year of the Application Programming Interface (API). Last year we witnessed huge adoption rates and record breaking levels in investment. For example, APIs listed in the Programmable Web directory crossed 10,000 for the first time. Now that we are well into 2014, we are going to see a huge leap forward in how APIs are put to use to drive innovation and help organisations be more efficient and profitable.
Although APIs present endless opportunities for companies large and small – many supposedly secure devices have some kind of application programming interface. Without the correct planning or preparation in place these devices can present malicious users with the perfect opportunity for hacking or data intrusion. What immediately may jump to mind is social network or email hacking, but when you consider that many APIs are linked up to satellites, mobile banking, automobiles or even weapons, the risks and possibilities are significantly multiplied.
So now the foundations have been laid, it’s time to tighten the API net and stop any potential privacy and security threats slipping through the cracks. Below, you will find seven simple steps to securing your APIs and if applied correctly, you’ll be reaping the benefits; future customer and community engagement just to name a few.
1. People Will Crash Your API Party
There is no ‘VIP list’ when it comes to accessing and analysing APIs. The reality is, if you don’t document your API as part of an API management strategy, someone else will. You cannot rely on “Security through Obscurity” for your API. For example, hackers have crossed into new frontiers by devising sophisticated ways to steal large amounts of personal identification numbers, or PINs, protecting credit and debit cards.
The most common method criminals are using to get the PINs, is to fool the application programming interface of the hardware security module in to helping them “understand” or manipulate one key value. Completely locking access to your API is not a reliable and effective security strategy. The moment your API is born, assume someone will try and gain access.
2. Keep Tabs On Your APIs
A weak audit trail is a database security threat. For a fairly obvious statement, you’d be surprised to hear that many organisations still do not clearly and securely document how their APIs are being used. This results in their API “flying blind”.
To resolve such common issues, audit trails are key. These will not only provide organisations with a trail to investigate API attacks, but can also act as evidence to ensure you are complying with industry regulations. For organisations in highly supervised industries such as the banking or health sector, this type of access to information can be critical. Maintaining an organised, easy-to-use system, keeps this information within easy reach at all times.
3. SSL: Older Is Wiser
Although Secure Sockets Layer (SSL) is traditionally viewed as the transport layer, and perhaps even old, it should always be used to underpin your APIs security when using Web transports. The Secure Sockets Layer (and more recently TLS) is standard security technology for establishing an encrypted link between a server and a client—typically a web server and a browser.
SSL has set the standard for API management as it allows sensitive information such as credit card numbers, social security numbers, and login credentials to be transmitted securely. Normally, data sent between browsers and web servers has been sent in plain text—leaving you vulnerable to eavesdropping.
If an attacker is able to intercept all data being sent between a browser and a web server they can see and use that information. Although new standards such as OAuth are perfect compliments to SSL, it is important to understand that they work together, and are not a case of “either/or”.
4. Tried, Tested & Recommended
Authentication is the process of identifying whether a client is eligible to access a resource; normally these come in the form of HTTP. However, over the past few years the huge explosion of technological development brought with it, dozens of new authentication schemes; SAML, SSL, OAuth and OpenID, just to name a few. Considering the number of options available, it may seem tempting for your developers to just create their own for a more personalised platform experience.
However, bear in mind there is a reason why these standard protocols exist. Not only does creating your own authentication mean more work, but you also risk multiplying the security risks tenfold, and it is all your own responsibility. Don’ be tempted to “roll your own”.
5. Security & The API Remain Independent
Separating the business and security platform of your API is critical for long term success. If you go ahead and merge the two, you will face several issues, particularly if you ever want to modify the security policies. Essentially, mixing the two areas will have a knock-on effect from either side, impacting the performance of your network.
Placing the security network on a completely different platform will guarantee you have the power and capacity required to protect your business API. Additionally, you are then able to make any tweaks required without affecting the other component of the API.
6. Prepare For Web App Attacks
Just because APIs are a fairly new technology, does not mean they are immune to more traditional forms of attack. Web APIs can be seen as web apps, so security risks such as cross-site request forgery, cross-site scripting and SQL injections still need to be monitored and blocked.
This is why it’s absolutely critical for an API management system to include Web application security. Only when it has the capability to do this, will you have peace of mind knowing you are protected against all forms of Web application attacks.
7. Protect What Is Offered
Just like shopping for new shoes, the beauty of an API is that there are several sizes and types available, so you are not restricted to only one option. However, personal preferences or favouritism can usually get in the way and cause risk. Without validating and protecting both XML and JSON, you will jeopardise the security of the API. Your customers will all have different preferences, so be sure your API is all encompassing, thus serving any preference that may arise.