API Security Trooper
It is not uncommon to see APIs being served using the “http://” protocol and it’s sad, real sad. So sad that every time I see it, I feel like crying.
I remember going to a hackathon few months ago and the idea of a location based Tinder-like app for LinkedIn popped. The question of whether we would let people sniff data flowing through the ether was raised almost immediately. What if people could tap into your stream over insecure WiFi? The decision was easy. We would implement a secure layer which we would allow the app to communicate with the server’s API.
I believe that doing things properly, by following best practices, is always more rewarding than just “hacking” things together. It is good training for your brain; it is the same reason why you don’t just decide to run a marathon without preparing for it physically and mentally. Adding security to your API should be a priority, not an item at the bottom of your to-do list!
#SSL and TLS
SSL stands for Secure Socket Layer, and if the name isn’t giving it away, it is a technology that encrypts data so that only the sender and the receiver know what message is being exchanged.
SSL was invented by those amazing folks at Netscape (specifically Dr. T Elgamal), the same guys who invented web-browsing as we know it today. Today, SSL has evolved into TLS (Transport Layer Security), and is responsible for the S in the “https://” protocol. In its simplest form you can see it in the browser when you navigate around websites. Essentially, most websites which don’t just serve static pages of information use TLS or SSL.
How authentication works
Let’s assume Alice is browsing a website bank.com
- Alice’s browser sends a handshake message to bank.com’s Webserver to initiate a secure session. Here, the browser and server agree on encryption methods that will be used and some other information about the session.
- The Webserver then sends the server certificate, along with information to identify himself (so Alice sends data to the right server) and its publickey, to Alice’s browser.
- The browser verifies the certificate and sends a message with it’s own information to the Webserver. This information sent by the browser is encrypted with the Webserver’s publickey received just moments ago
- The Webserver decrypts the one time message with its privatekey
- Connection secured!
Keep in mind: The only way you can decipher messages encrypted with a publickey is by using a privatekey. This way, you will not be able to read what Alice’s browser and the Webserver are saying unless you get hold of the Webserver’s privatekey.
#B-b-But I’m not building a website, why do I need this?
An API allows an interchange of data between two parties. It also requires the client to send a password (apikey or token) to identify itself with the server, thus requiring that piece of information to be accessible by third parties.
It matters for a number of reasons:
- You are a Bank software developer working on an online banking app, and you don’t use TLS or SSL: Random users around the world can start sniffing transaction requests, capture APIkeys of your customers, along with details and other information from your clients’ account.
- You’re a user of NotSoCoolInbox and its relative mobile app. Unfortunately, the app on your phone does not check for authenticity. Every time it uses the API to retrieve email metadata, it doesn’t know whether it is contacting the authentic server. Therefore you don’t know to whom requests are being sent to, and from whom responses are being generated. Great, you might have just given the access of your email account to some malicious person. Or worse, you’re getting fake/compromised information back. Not ideal!
SSL is not only extremely good at hiding information from the eyes of malicious users, but is also used to ensure you’re communicating your data to the right end.
Using unsecured communication channels is like inviting thieves to your house!
API Security is important
Securing your API is important. In e-commerce, there is a ton of focus on ensuring that authentic TLS/SSL certificates work properly. Why shouldn’t you protect customers using your API service?
Every request you send to Mashape occurs over a secure layer using TLS/SSL. Your client trusts our connection which is designed to prevent eavesdropping from malicious users.
Self-Signed vs Authority Signed Certificates
Because TLS/SSL works with certificates, you need to either generate one yourself or buy one from a trusted authority. The latter option costs money, while the former is free!
To generate a pair of certificates on your server, you can use commands below, make sure you’ve got openssl installed!
openssl genrsa -out key.pem
openssl req -new -key key.pem -out csr.pem
openssl x509 -req -days 9999 -in csr.pem -signkey key.pem -out cert.pem
On top of using TLS/SSL, you also need to use an authentication method, such as OAuth or Basic auth.
Mashape’s proxy supports OAuth, Basic + Header Authentication, and Parameterized Authentication. If you use any other system to authenticate your API, do let us know and we’ll tell you if we’ve got plans to support it!
This post was written by an awesome Mashaper:
Orlando likes to talk to developers, API enthusiasts and hackathon goers! Feel free to reach out to him on twitter for any Mashape related questions or general chit-chat