One good practice is to write code iteratively, testing every time we make a new small feature or improvement, and always write code thinking of all the features we envision for our service.

Thinking about the service roadmap allows you to prepare the service for future improvements, reducing the amount of code wasted or replaced later on.

For instance, in terms of security:

• Is our service secure? Is it prepared for some types of malicious attacks?
• Is our service private? Should it have some kind of authentication or authorization mechanism?

Luckily, our frameworks allow our code to be composed and allow us to add layers of security later. For example, using Express or Hydra, we can add a precedent routing function that will run before any of our service methods, allowing us to enforce, for example, authentication.

Looking at our service, since it exposes its methods using HTTP, there are a couple of improvements we can add to it, for example:

• Authentication: Forcing anyone that uses it to identify themselves. Or, just the upload and removal methods. It's up to you. There could also be user accounts, and each user would see their respective list of images.
• Authorization: Restricting, for example, what networks could access the service, independently of having a valid authentication or not.
• Confidentiality: Giving your users protection against prying eyes over the network traffic.
• Availability: Restricting the maximum usage frequency of the service, per client, to ensure a single client cannot block your entire service.

To introduce these improvements, you may add an authentication module such as the Passport module, and use a certificate to give your users a more secure HTTPS experience.

Other types of insecurity come directly from your code and don't improve by adding a certificate or forcing authentication. I'm referring to:

• Bugs, programming logic flaws, and use cases not properly tested, which can lead to minor or serious problems
• Dependency bugs, which you might not be aware of but can still ruin your service and may force you to look for alternative dependencies, which is never a pleasant task

To minimize these events, you should always keep evolving your test suite, adding use cases as they show up, ensuring a new bug that is solved does not reappear later. Regarding dependency bugs, you can subscribe to the Node Security Project and even integrate it with your code to always know when one of your dependencies is a risk.

If there were source code commandments, the next four would surely be on the list:

• Keep the code simple. If the code is getting complex, stop, look back, and split the code into simpler parts.
• Validate external input, whether it's the user or another service. Never trust data from the outside.
• Deny by default and not the opposite, checking whether someone has access to a resource and denying anyone that is not.
• Add test cases from the beginning of the project.