I know you’re running a company and gunning at 500 miles an hour, trust me I make a living building things fast, so I get it. However, you don’t need to go to the nth level of security but at least do basic things when building out your product so you don’t end up in the news for the wrong reasons.
Here’s a super short article on some of the basic things you can do to ensure your product is “safe” to some extent. Of course, you can really amp this up with ridiculous security practices, pen-testing, ML-based anomaly detection software, internal LAN networks and firewall and 2 Factor Authentication - the list can go on.
This article is going to use a node and AWS as an example - I'm pretty confident the same principles will apply to your stacks too.
1. Hashing passwords
Yes I know, its taught in bootcamps and 1st-year Uni, yet its sad that I need to bring it up. Hash your passwords using bcrypt and salt rounds. Salting is a randomised string generated and represents the cost factor, and the goal of salting is to prevent your system from getting hit with a rainbow table to brute force passwords.
Some bcrypt best practices:
- Perform UX research to find what are acceptable user wait times for registration and authentication.
- If the accepted wait time is 1 second, tune the cost of bcrypt for it to run in 1 second on your hardware.
- Analyze with your security team if the computation time is enough to mitigate and slow down attacks.
2. Load all ENV variables through your pipeline
Using AWS Parameter Store, Elasticbeanstalk set up, and your pipeline system, use variable identifiers in your pipeline such as DB_URL=$DB_URL to inject sensitive values into your backend environments.
Make sure the variables are different for your prod and staging environment.
Make sure those variables are accessed by restricted IAM accounts.
3. VPC Networks
Its super simple to set up but a Virtual Private Cloud in simplest terms can be thought of as a house where all the people in the house can freely communicate with each other and only a certified person is allowed to open the door. This house is in a community that is freely accessible.
Think of the community as a public cloud and the house a private cloud within the public cloud.
The official wiki definition is: A virtual private cloud (VPC) is an on-demand configurable pool of shared computing resources allocated within a public cloud environment, providing a certain level of isolation between the different organizations (denoted as users hereafter) using the resources.
You can set up the DB so that only systems within the VPC can access your DB.
If you want external access to your DB make sure in your inbound rules, you whitelist all IPs.
Image creds to znetlive.
4. CORs Access
A super simple thing to set up in a node environment and only allow request access from whitelisted domains.
This will prevent anyone just using your auth token to then get access to the DB without the restrictions of the UI (so to speak)
5. CRTFs
Whenever you're doing social authentication like Google, FB or LinkedIn(compulsory)
Its worth setting up a secret (hard to guess) key when you make your redirect call. On return of the call make sure the secrets match, this ensures there hasn't been any tampering done to the request and the request is pure.
Here's a quick link of what https://en.wikipedia.org/wiki/Cross-site_request_forgery is.
6. Bonus mention
Don't copy production data to weaker environments to test your product. Make sure production is untouched and development environment covers the edge cases you're solving for.
Creds Alex Joyce
There you go, some super simple and basic things to set up that won't take more than a few minutes.
Using this a bare minimum base, you can amp it up to the nth level - I'll be sure to update this as I can think of simpler ones.
And of course, if you've got more that you'd like to share, please put them in the comments because it'll help me and others alike!
Top comments (0)