Make sure your web application is production ready!

Don’t move to production if you are not ready!

Hello all 🖐 In this article, I’d like to share with you some of the important and basic configurations which must be applied before deploying your web application to production. Following only these rules alone is not sufficient, because there are many more things that you must take into account before making your application live. I have created a curated list of things that may help up to some extent. I’ll also share with you more configuration tips and techniques in my upcoming posts as we cannot everything in this single article.

Some code snippets used in this article will be written using JavaScript (Node.js), sorry for that. Also, I understand that most of the points will be already covered in various articles out there, but I hope you may learn something new from this post.

1. Never hardcode sensitive information within your source code :

Always load the sensitive information like API_KEY, Secret Tokens, etc, from the environment file. Even if you commit and then delete and commit again it can still be retrieved as it resides in the git history which is also bad.

Also, make sure you have a private repository for the source code. Today there are lots of bots scanning the public Github repos at all times looking for such data and also there are many extensions that can be used to find the .git folder from websites if accidentally committed. So the bottom line is: keep your data safe!

Even the env variables are not completely safe, so if it contains any sensitive security credentials make sure you encrypt them before passing them as environment variables.

An extra layer of security, of course! 💫

Example:

If you are using Node.js then you can easily load environment variables using the dotenv npm package like this :

2. Be careful while configuring CORS :

I would recommend restricting the request origin to your server if your application deals with CORS. Because anyone can easily bombard your server which may result in a DDOS or similar attack which is highly undesirable in production systems.

There are also other types of attacks like CORS Abuse, etc… So, if implemented badly, CORS can lead to major security risk like leaking of API keys, other users data, or even much more

So use a middleware that will validate the incoming request origin. We can add a list of whitelisted domains. If we get any request from an unknown origin, we can simply throw a 403 Error.

Example :

3. Always validate the request :

While implementing the controller for endpoints, we must always ensure that we handle every possible case. To make this process simpler, we can also follow the Test Driven Development style. Also, it’s suggested to catch the errors and throw appropriate error messages to the client. We must be careful in displaying the error message to the client.

Example :

If we don’t validate the request before processing, then the error will be caught by the catch block, also we may need to rollback in case if it involves database updates, which is tedious and dangerous in production. Hence we must add appropriate validations wherever necessary.

4. Be cautious while displaying error messages :

Once the website/web application goes live, hackers or malicious actors may try to find vulnerabilities in the platform. Hence, we must be cautious in displaying the error messages to the end-user.

Lets say that a user tries to login using wrong credentials :

The error message can be just “Invalid credentials”, it’s not necessary to display something specific like “Invalid password.”, because it indirectly specifies that an account with that email is registered at the platform. Hence, the hacker or malicious actor can easily brute-force and obtain a list of emails registered at the platform.

5. Don’t forget to remove the console.logs() :

It’s a common mistake that, we may forget to clean the console.log() statements before deploying the code to the production server. We will use log statements for debugging our application during development. But, once everything is properly tested, we must remove all the log statements from our code. Because without our knowledge there are chances of exposing serious information that is highly undesirable.

For example, say you have found some bug in the login service and trying to debug the issue.

The above code is safe as long as it resides in our development environment. But once migrated to production, then it is highly unsafe as we expose the password (in plain text). Hence we must always make sure that all the log statements used for debugging are removed before moving to the production environment.

If your application already follow these rules, then give yourself a clap 👏.

Conclusion :

Yes! In this era of the modern web, there is nothing called “this is the correct way” to do stuff. But, there are certain best practices recommended by the industry experts that can be followed to save ourselves from catastrophes in the application. It’s not like “I’m a developer, not a security expert”. Every developer should understand and follow basic security practices to create a better web. If you have any queries or thoughts, please feel free to add them in the comments. I’ll be happy to know!

There is still more stuff we must take into account to give our application the production-ready tag. I’ll keep sharing them in my upcoming posts.

Stay tuned…👋👋