5 Bad Coding Habits That Leave Your Source Code Exposed

In 2020 the average cost of a data breach was $3.86 Million. There are many ways that you can be proactive about your security to prevent this from happening to you. And the cost of doing so is far less than the cost of a data breach. Secure coding doesn’t cost anything in and of itself. It is a mindset and a philosophy your organization can (and should) adopt to protect its assets.

By increasing awareness of bad coding habits, you can start being proactive about the integrity of your source code. Are you ready to shed those bad habits and form better, secure ones? Let’s get started.

What Is Secure Coding?

Secure coding, sometimes also called secure programming, involves writing strict code, to be proactive towards potential security vulnerabilities. Vulnerabilities that may expose data or cause harm to the system in other ways. 

However, secure coding doesn’t refer merely to writing good code. Secure coding must be developed in a secure environment, on secure platforms. And of course, in the age of cloud computing, all services such as platforms and software must be configured correctly to prevent breaches.

Why Does Secure Coding Matter?

When organizations have major security breaches they do not always disclose the nature of the security breach. This is because even if they were responsible, know what caused it, and have fixed it – the information on how it was achieved would still be valuable knowledge for future attackers. But it is easy to imagine how insecure coding may cause a significant portion of those issues, especially data breaches.

Data breaches are probably the scariest and costliest security breach. In 2020 alone over 25 billion records have been leaked or stolen, and estimates for 2021 are that it is only going to get worse. Organizations need to step up their security protocols, and secure coding is at the core of those security protocols. Without secure coding, all the other security protocols are going to fall short of protecting your most valued assets.

The Top 5 Behaviors That Compromise Source Code Integrity

The focus here is common behaviors adopted by developers, usually early in their careers. Those behaviors, if they remain unchecked, can cause serious maintenance and security issues in the near or far future. Make sure all developers in your organization are aware of those bad practices and learn how to avoid them.

1. Unchecked copied code

I have heard copy-and-paste programming referred to both with contempt and high praise. Sometimes development requires a core bit of functionality that has been coded tens of thousands of times by other developers. So why not copy their work rather than write it from scratch? Most times you definitely should use someone else’s work, but you must be smart about it.

Understand the code you’re copying. If you decide to copy code, make sure you read through it and understand it. Just like when you would when reviewing a colleague’s code. Never blindly trust that someone on the internet has done a good enough job writing a piece of code and made it public. Verify.

Use libraries where possible. To an extent, using libraries is preferred to copying code. If you need some string handling functionality, you’re likely going to need more of them in the future. Using a library that handles strings is probably a good addition to your project. Of course, you don’t want library bloat. So you must carefully select the libraries you add to your project. If you’re only ever going to need one function, it might be better to just copy it than use the entire library.

2. Deprecated, abandoned, and suspicious libraries

There is a lot of bad code out there. Sometimes open-source code gets packaged into a library without being properly vetted by the community. This can result in code that has security vulnerabilities nobody even bothered to recognize, let alone fix.

When using libraries, make sure they are libraries that are widely used and monitored by trusted organizations or a large volume of developers. Those libraries should be maintained and regularly updated. If the library hasn’t been updated in a decade, you’re going to need to review the entire code base before incorporating it into a secure project. Otherwise, you can’t trust it.

3. Unrestricted repository access

In today’s climate, there is a tendency to trust developers with unrestricted access to source code repositories. This is a major security vulnerability. Developers don’t need access to everything, they only need access to the areas of the code they are working on, and they might not even need write access.

Having restricted access can sometimes slow down development, but more often than not it will help maintain decoupling and modularity of your code. If a developer can only make changes to the module they are working on, they are forced to remain decoupled from the rest of the project. This is a good thing even without regards to security

An employee without access to the entire source code has very limited ability to do damage, whether out of malice or incompetence. But even under a restricted access policy, IT must revoke access to source code repositories when a developer leaves the organization. Having unused credentials lying around is having a problem waiting to happen.

4. Hardcoded secrets

Secrets are any online credentials that provide application-to-application access. It can be API keys, cloud credentials, encryption keys, database access details and many more. It is common practice among inexperienced developers to use plain text secrets in their code for initial development. Often, those secrets are forgotten and left behind, causing a potential leak.

Source codes hosted on public cloud services like GitHub can be easily scanned by malefactors and exploited. Make sure to scan code for secrets before uploading it to the cloud.

But even if the source code is never exposed, most compiled code can be reverse-engineered. Obfuscation can help increase the difficulty of reverse-engineering compiled code. However, it is much better to properly store secrets in a way that prevents leaking. 

5. Exposed information in error messages

Debugging code using verbose error messages is a common practice among developers. But these error messages might provide information to attackers looking to break into your software. Error messages need to be helpful to users but not provide any information regarding how the code works.

Hide information regarding code structure, data structures, and connections to other software. Also, make sure that exceptions are caught and processed. Uncaught exceptions often provide a stack trace that is ripe with information an attacker can use. Catch all relevant exceptions and don’t throw unchecked or runtime exceptions that won’t be caught down the line.

By being aware of those bad habits and how to develop better ones, you are already working on developing more secure code. Armed with this knowledgeת be mindful of any habits you may have, and make note if you think they may cause security issues. Bring it to the attention of colleagues and you may find others do the same. Find a solution together and form new habits. It’s much easier to change habits if others are changing theirs alongside you.