As a back end developer, we have a big job. We make apps that manage people’s data and we can make code that does many things to them whether they’re good or not.
In this article, we’ll look at some best practices to take note of when we’re developing back end apps.
Use Docker to Sandbox Apps
Docker is a great program for letting us run sandboxed containers. Therefore, we should use them to host and run our back end apps.
This way, all apps run in their own container so they can run in their own environment. This means that any binaries that we don’t trust can’t run outside the Docker container.
Also, any changes that we do to the Docker container are removed if we rebuild the Docker container, so if we or some attack mess up the container, we can just rebuild it and we put it back to a working state.
The libraries and dependencies of the different app won’t interfere with each other.
Also, multiple containers running on the same ost will have some level of access to other containers and the host itself.
Therefore, we should secure all hosts and run containers with a minimum set of capabilities.
We can do things like disable network access to a container if we need to.
Credentials Should Never Be Sent Unencrypted Over a Public Network
We should never send credentials over like SSH keys and passwords over a public network unencrypted.
There’re many ways to secure this. We can encrypt it, or send it through a password manager or something like that.
Never Store Secrets in Source Control
Secrets should never be checked into source control. It’s very easy to do that and then we have to reset them if they end up there.
Checking them in increases the risk of exposure to malicious people so we shouldn’t take that risk.
Even if we change the file permissions of the secret file, source control systems often unwrite those file permissions so that they may be made publically readable again.
Therefore, we should put our stuff in a file that won’t be checked into source control.
Whatever the name is, it should be ignored.
Login Throttling
In our back end app, we should limit the number of login attempts that users can make per a unit of time.
If the user fails to log in after a few tries, for instance, like 10 failed attempts, then we should lock them for a short period of time like 5 minutes.
This way, attackers can’t do brute force attacks easily.
User Password Storage
Passwords should never be stored in plain text. If we need to record passwords, then they should be stored in something that doesn’t show the password.
For instance, we can use a password manager to store our passwords.
We can use asymmetric encryption to store our passwords so that we can store them encrypted with a public key and then decrypt them back to plain text with a private key.
Passwords should be stored as a one way hash in most cases soo that they can’t be decrypted even if attackers log on to our database.
We encrypt each password with a secure hash and salt and just check against the hashed password if we need to check against it for authentication.
Audit Log
Our app got to keep an audit log to know who did what. The more critical the activity, the more logging that we need to do.
This way, we can check for suspicious activities if needed.
This way people can know what people did at what time and what’s the previous value before the change and the value after.
Each log entry should have the time, user who did the action, the action, and the old and new values.
It can be stored as a separate log file or part of the regular application log. Or it can be stored in the app database so that we can query the entries.
Conclusion
We need an audit log to check for suspicious activities. Also, we need to throttle login attempts so that attackers can’t use brute force attacks to log into in an authorized manner.
Also, we should never expose passwords to the public.
Finally, Docker is great for sandboxing apps and minimizing attack surface.
