Basic security for developers

Protect your accounts, your secret keys and your machine with a few simple habits that stick.

8 min · 3 questions

You do not wait until you are an expert to protect yourself. From your very first week you handle sensitive things: an email account, an account on a code platform, sometimes access keys to paid services. A few habits picked up now will save you very concrete trouble later, like a bill for several hundred euros run up on a stolen key.

Start with your accounts. A different password for each service, long rather than complicated: a phrase made of four unusual words beats a twisted eight-character word. Use a password manager so you have nothing to remember. Then turn on two-factor authentication, on two accounts first: your email and your code account. They are the keys to the kingdom, because they can reset all the others.

Next comes the question of secrets in your code. A secret is an API key, a database password or an access token: a string of characters that proves you are you. The rule is absolute: a secret is never written directly into a code file. You keep it in a .env file that stays on your machine, and you add that file to .gitignore so it never goes online.

# .env: stays on your machine, never shared
API_KEY=secret_key_do_not_publish
DB_PASSWORD=local_password

# .gitignore: tells Git to ignore these paths
.env
node_modules/

Finally, be wary of commands found on the internet. Never run a line you do not understand, especially if it starts with sudo: that word means "with administrator rights", in other words the power to change or erase anything on the machine. Same caution with install scripts that are downloaded and run in a single move.

# Avoid: this runs without you having read anything
curl https://example.test/install.sh | bash

# Better: download it, read it, then decide
curl -o install.sh https://example.test/install.sh
less install.sh
bash install.sh

Knowledge check

Make sure you remember the key points of this lesson.

1. Where should you store an API key in a project?
   • Straight in the code file, it is simpler that way
   • In a local .env file, excluded from the repository by .gitignore
   • In the commit message, so it is easy to find again
2. You published a secret key by mistake, then deleted the file. What do you do?
   • Nothing more, the file is gone
   • Revoke the key with the service and generate a new one
   • Rename the repository to cover your tracks
3. Why be wary of a command copied from the internet that starts with sudo?
   • Because it always runs more slowly
   • Because it runs with administrator rights and can change anything
   • Because it only works on Windows