Shoddy Code is Behind Many of the Biggest Recent Data Breaches

It’s an unfortunate side effect of our current tech landscape that we’ve become desensitized to news of another major corporation suffering a massive data breach. They happen all too often, for far too avoidable reasons, and companies refuse to learn their lessons. Although there are a variety of factors that lead to these hacks, at their core they usually revolve around human error. 

More concerning is that many of these breaches are happening at the application level, and not through more well-known vectors such as phishing, ransomware, and malware. A 2018 study found that nearly 46% of all data breaches occurring that year were application layer attacks. This is concerning, as it reveals that a large problem with today’s cyber security isn’t necessarily a more dangerous ecosystem (although that undoubtedly plays a part) but rather shoddy development practices. 

While it’s not realistic to say that simply implementing better coding standards would completely resolve the issue of data breaches, it can still make a major difference. By emphasizing security and smart development from the start, organizations can better protect their investments and ultimately, their users. 

Bad Code Leaves Holes

Even though stolen passwords, hidden malware, phishing scams, and other threats remain a major culprit in data breaches, programs themselves are often not built with security being top priority. Poorly built code, vulnerabilities left unpatched, weak database design, and other application level mistakes can be infinitely more costly when hackers know exactly how to exploit them. 

The problem with bad code is that it’s not often obvious if there is a major issue. When code is developed simply to get the job done quickly, programmers may take shortcuts or apply less-safe techniques in the interest of expediency. Moreover, when code is changed simply to fix one issue without considering the broader impact, it can lead to unforeseen security complications and bugs. 

Facebook’s massive data breach, for instance, was the result of a few lines of faulty code that gave Cambridge Analytica continued access to users’ data. The result was the leak of nearly 87 million people’s private and personally identifiable information without their knowledge or consent. The Equifax breach, which resulted in the theft of 143 million users’ information, occurred through a web application vulnerability that went unpatched. Yahoo!’s historically massive breaches in 2013 and 2014 were caused by obsolete code and lax security measures. 

The common thread here is that these companies emphasized quick results and simple solutions over measured approaches such as secure coding, which stresses building safe applications from the start. 

Focusing on the Wrong Things

Faults in code aren’t usually intentional, and most times they’re caught long before they pose a risk. However, they stem from a common cause—a results-driven approach that ignores the processes used. Coders who constantly look for short term band-aids to problems tend to ignore the implications of their “fixes” on the broader application, and especially on its security. 

Fixing a small bug with an application breaking script can undo months of hard work. A developer who keeps getting an exception during a runtime test may simply write a script to ignore it instead of shutting down a process. However, that fix could mean that other aspects of code are also affected, or other exceptions unexpectedly ignored. Moreover, hackers can easily use an ignored error condition to game a system and destabilize an entire application. 

It is crucial for app development to focus on processes as well as results. A finished application that’s full of holes is just as good as one that’s never launched. Secure coding sets forth standards designed to ensure that code always prioritizes safety and security as well as usability. This includes creating simpler code that’s easier to understand and fix, implementing automation to reduce human error, and creating threat models to form a better understanding of possible vulnerabilities. 

They key aspect is that instead of focusing on post-development security and patching, teams can bake in these processes, ensuring a higher chance of success and a greater degree of safety. More importantly, it mitigates the danger of unintended consequences and overlooked bugs that could be catastrophic for any application. 

Security First, Not Last

There is a common misconception that security comes after an app has been built in the form of patches, security software, and other tools. However, many breaches happen not at this level, but directly on the application layer. Bad code, unfixed vulnerabilities, script injections, and unseen bugs can all be just as damaging as an employee forgetting to log out of their account or forgetting their password. 

It’s vital to focus on security from the start to reduce the likelihood of a catastrophic breach. More importantly, it helps relieve the stress of planning security for an inherently insecure application