Photo by Michal Matlon / Unsplash

Keep it Simple, Stupid!

Architecture Apr 28, 2022

Something often discussed in the tech world is how to prevent opening up your architecture to security vulnerabilities and how to ensure that your infrastructure is "safe" from malicious actors. While there are many trains of thought about this subject I wanted to touch on one part that I consider a critical way of thinking when designing a software platform.

This is by no means a full guide and you should consider checking out other blogs for more critical information if you want to dig further into secure architecture. (list below)

The idea is simple, as the name implies but it's not so much a way to tune a platform as it is a way of thinking. If you're designing anything in the software development lifecycle keeping it simple will save you from many major headaches down the road and it could save you from opening yourself up to major problems. Keeping it simple means you should only use what you need in order for your platform to function and constantly maintain this simplicity by removing parts that you no longer need. This can apply to everything from DevOps to frontend development, and if you think about it many major problems come from outdated things that nobody knew were there or some port exposed that was unused and slipped by detection because everyone forgot it existed. Major services have come in to cover the gap left in the old post "cloud" internet that automatically disable everything you're not using and that's a step in the right direction but not the full story.

Too many times companies get caught up in buzzwords to understand the true value or consequence of the things they are introducing. Nowadays there's a million services for everything you want to do no matter how simple. Knowing buzzwords and implementing arbitrary platforms is not the full story though; in fact it can set a dangerous precident and open your platform up to major problems.

But Why?

Let's look at some simple examples to illustrate the point a but further

  1. I am a DevOps Engineer and my company has tasked me with deploying a new enviornment to a dedicated (or virtual) server
  2. I am a Backend (or Full-Stack, titles are useless) Engineer and my company has tasked me with adding a feature to the API codebase
  3. I am a Frontend (or Full-Stack, titles are useless) Engineer and my company has tasked me with adding a feature to the website
  4. I am a Frontend (or Full-Stack, titles are useless) Engineer and my company has tasked me with adding a feature to the mobile app

  1. When deploying a server you should first ensure that only the ports required are open and everything else is rejected automatically. You should ensure that the only software that is running on the server is software that is consistently updated and required for the function of your company's application. This prevents you from two potential exploit vectors: Open ports can allow access from outside computers, sure it may be unlikely in some cases and if you have nothing listening, oh well! but close it all up, no need to leave things hanging that could become a nightmare later on. Software that's not needed is likely to slip behind audit and leave you open to attacks from the software itself or something within the software such as a code exploit (as we have seen with many NodeJS things over the past few months), it could leave your server exposed even if the software just stops being updated and remains in your system and then a new explot is developed for it and surprise! You're running the exploited version. The simplest way to remain safe is to not have it at all.
  2. When writing backend code you typically have access to vital resources that the frontend does not, such as database connections, so you have to be extra cautious to secure your code against potential attackers. Remember that your code is being consumed by any amount of unknown persons at any time via the endpoints you expose. Thus you should strive to remove old, outdated code as quickly as possible and keep your backend codebase slim. This includes libraries which may just be the most important part! Don't use them unless they provide meaningful assistance, save time and are being continuously updated. It's your job to keep them updated in your project too and you should do that. Again, keeping your code and your dependencies simple will save you headaches down the road even if you're work is never exploited do you want to sift through 500 dependencies to find a bug? Didn't think so.
  3. Much of this is similar to above but the number one thing to remember here is that your code is running on any arbirtrary machine that accesses it. That means that no matter how secure your code may be you can still leak information and vital assets by simply having too much there. Keep your dependencies simple, your API information, any critical information especially. Don't let your code get so complicated that you forget about some arbitrary key buried deep within the code and suddenly your backend team is spamming you on Slack about a vulnerability. Frontend software has libraries as well and you should also keep them simple if only for the sake of your users who could end up in hot water for your mistakes if you're using vulnerable code. Frontend applications are desktop applications in scope so your code is running entirely on the users' machine, don't forget that.
  4. Similar to #3 mobile apps are typically restricted from your platform by communicating exclusively via API calls. That doesn't mean that you shouldn't keep it simple, consider this: You allow file upload and the backend developers are terrible at their job and allow anything to come through and be processed (okay, this is not the best example but it gets the point across) assuming it will be covered by validation on the frontend - but the library you npm install'ed hasn't been updated in 5 years and now allows arbitrary files. You've just opened yourself up to a portential attack vector.


The plan is simple, think about what your infrastructure, code, etc. needs and do that and nothing more. Furthermore make sure that nothing more is even possible. Impress your boss with the knowledge of platform needs and what should be shed as dead weight from the project 😎

Consider checking out Dependency Hell, Slow Down! and Clean Coding for some equally important and similar views.

Other Resources



Senior Software Developer working with software since age 17 (all the way back in 2008!)