We are back on track with Andrei’s tech series. This time he’ll explain the right way to secure the API – back end validations first, front end validations second. He shares with us the best practices for API security at application level (useful for back end devs) and server level (useful for devops). Discover more in the article.
API security does not happen in the browser. This is a very important aspect that a surprisingly large number of people are not aware of. When an application is running, it exposes an API that is accessible from any client capable of transmitting a request to it (curl, postman etc).
No missed out backend issues
Securing a form in the browser (like performing validations) does not help with overall security. It does however help with performance, mainly because the users won’t flood the server with invalid requests and won’t have to wait for a client-server round trip on every submit.
If front end validations are specifically required to help with performance, the best thing that a team can do is to develop the backend validations first, test them, and only after that develop the front end validations. This is very important, because if done the other way around, the testers will miss out on every possible back end issue (it does happen a lot).
APPLICATION LEVEL
(this applies to back end devs)
Before we start, here’s an advice for you:
Never test the API from the “front end app”, but use a HTTP client instead (postman works great). Why? Always a good question. First of all, you detach your head from all the front end logic, which makes you think better in terms of API security. You become to think a little more paranoid, like anything could come through a request (which is perfectly true). I guarantee you will discover at least some security flaws by working this way.
Second, it’s a lot faster. You create a request just the way you want it, then save it and execute it by the press of a button. No need to reload the client app and fill forms and get frustrated because the bug is still there. Third (and most important), when the front end guys complain to you that a request doesn’t work (which they usually do), it’s like you have a button which can close their mouths. And that’s priceless!
The main concerns when dealing with API security are: authenticating users and managing user permissions.
Best practices for API security
1. Keep your code libraries up to date! You rely on them more than you think. Cypher algorithms are cracked all the time and stronger algorithms are constantly developed. A whole bunch of contributors are working to keep you safe. Why not benefit from it?
2. Never keep user data in the token, only keep the user ID. Otherwise, one of these may happen:
admin revokes a user’s permission, but the user still has a token with that permission
token gets decoded, data gets stolen
3. Always receive sensitive information via the request body.
4. Never let the users tell you their identity. Always identify a user through your security mechanism.
EXAMPLE: Wrong profile update request
A user profile update request looking like this is just wrong:
function updateSelfProfile(request, response){
//check if user making the request is authenticated
if(request.userIsAuthenticated()){
//get user id from a query param
var userId = request.query.id;
//get updated info from the request body
var updatedInfo = request.body;
//perform the update
updateUserProfile(userId, updatedInfo);
}
}
Even if the user goes through an authentication mechanism, it can still update another user without permission!
Make sure the user only has the rights to access the application. Something like “iptables” or the easier “ufw” works great for that.
SERVER LEVEL
(this applies to devops)
From a devops engineer’s perspective, the whole system is like an API, and each application port is like an endpoint. So the first thing we need to make sure of is the user only has the rights to access the application. Something like “iptables” or the easier “ufw” works great for that.
Another must do is to encrypt client to server communication. That way, if a third party would intercept the communication, it would have a very hard time reading it. For that, you can use HTTPS.
How HTTPS works
1. The server holds a pair of a PUBLIC and PRIVATE key. Stuff that is encrypted with the PUBLIC key can only be decrypted with the PRIVATE key.
2. The client generates a SYMMETRIC key. Stuff that is encrypted with this key can also be decrypted with it.
3. The server gives the client its PUBLIC key.
4. The client encrypts its generated SYMMETRIC key using the server’s PUBLIC key and sends it back.
5. The server decrypts the message using the PRIVATE key and gets the SYMMETRIC key.
6. Now both the client and server share the same SYMMETRIC key and they are the only ones who know about it. They can now encrypt their communication.
The most important thing to remember here is that in order for all of this to work, only the server must know the PRIVATE key, which is contained in the generated security certificate (usually the “.key” file). So keep it safe!
Keep up with Andrei’s tech series! Until now, he introduced API security, web security basics, and how to boost database security. In the next article he’ll explain why browser security is essential. You will find out the best practices on how you can protect the information in your browser. Stay close to find out more!
Want to keep up with the news? Read more on our blog or follow us on Facebook or Instagram to stay in touch with the cool stuff tech we’re doing every day.
No Comments