Never postpone your product’s security

Security isn’t that layer that you just add on top of your application before shipping it to production. Security is a mindset, that constant voice inside your head which asks “Is this safe?” each time you code something that pulls data out of storage or changes structures based on a user’s action.

Adding security later is as difficult as adding unit-tests to a product that didn’t have any. You can definitely do it, but the efforts will be exponentially bigger than if you had done it in the first place.

This is because security, like unit tests, might force you to change some data flow inside your components, that will lead to changing the way data is being fetched or persisted, which in turn implies more or less changes to your application. And we all know “change is hard”.

We, as humans, resist change because of an inner sense of inertia, a comfortable feeling that says “we are used to this, let’s not change it!”.

This doesn’t mean you should ask the user for any 13-digit prime number to be able to log into their account, but rather keep in mind that a user’s privacy is as important as your own. That not everyone out there has the best intentions. That many people have made a fortune by leveraging other people’s weaknesses. By selling corporate secrets. And some people only do it for fun, or to prove their worthiness. Even if it means publishing entire databases of customer information, including credit card information, passwords, and other sensitive data extracted from big companies such as Yahoo or Adobe.

Such an attempt on your users’ security, if successful, might even ruin your business and together with it, your dreams and goals. Your reputation among your circle of trust.

This being said, whenever thinking about postponing security for later, always consider the consequences of this choice. Because it’s always a choice. Nobody puts a gun to your head and says “If you don’t code this function in 10 minutes, I’m pulling the trigger”. The Product Owner or Project Manager of your team will never allocate you hours to add security to your feature. It’s up to every developer to add that in as they implement whatever the task at hand is.

“Security considerations” isn’t just a question that you answer with “Yes, I have considered security in this piece of code”. It’s something that you can actually enforce and concretize: building them within your unit tests. You do have unit tests, don’t you? ;-)

Whenever testing your code, check for security: make sure requests to your API or methods cannot access resources that they shouldn’t be allowed to access. You might even be surprised to discover one day, while implementing something, that some security hole suddenly pops out and a test indicates that some piece of code can get some information that it shouldn’t be able to get. That will be your “Aha” moment, when all your efforts to enforce security will prove to be worthwhile. .

As for who’s responsible for security, there’s only one rule: It shouldn’t be one person’s responsibility. It should be a team’s mindset.

Therefore, never postpone security! It will bite your ass just like never creating backups will: when you least expect it. And when it does, you’ll wish you did this in a different way.

Don’t leave room for regrets! Life’s too short for regrets.

–Photo by Paweł Czerwiński on Unsplash