Is One Programming Language More Secure Than The Rest?

DZone 's Guide to

Is One Programming Language More Secure Than The Rest?

This analysis of a recent state of open source vulnerabilities report sees which programming languages tend to be more secure for coding than others.

· Security Zone ·
Free Resource

Open source vulnerabilities are on the rise. Again.

Since 2017 we have seen a rapid rise in the number of open source vulnerabilities that are being reported by the community. This past year was no exception, with WhiteSource’s State of Open Source Vulnerabilities report finding that 6,100 vulnerabilities were published in 2019 over the 4,100 reported in 2018. 

While the news of a 50% spike from one year to the next was itself news, the research report also shed light on which languages had the most open source vulnerabilities, what were the most common vulnerabilities per language, and what those results tell us about how the software development community is building applications.

The Top Open Source CWEs per Language in 2019

Cross-Site Scripting (aka XSS or CWE-79) was the most common vulnerability type found across nearly all of the top programming languages, when it came to the open source vulnerabilities published in 2019. 

Only C led with Buffer Errors (CWE-119), while Improper Input Validation (CWE-20) came in second for most of the listed languages. 

Looking at the data, a common thread emerges that should concern the software development community. Namely that many of these vulnerabilities are caused when developers don’t properly restrict the actions that a user can take, compromising their web applications’ security along the way. 

By most accounts, these security vulnerabilities are considered to be the result of sloppy coding practices. If anything, the prominence of these vulnerabilities should prove to us that going back to basic coding standards is vital to security.

Rate of Published Open Source Vulnerabilities per Language 

Zooming out from the specific CWEs, the report also looked at how open source security vulnerabilities’ distribution had changed over the last year in these popular languages.

While C is still the language with the most reported open source vulnerabilities at 30%, that is because it is one of the oldest languages there is, used by some of the most popular open source projects that we are all using. Whether you’re a lover or a hater of C, there’s no denying that no other language can compete with the volume of code written in C. 

However, what is fascinating is that the biggest change was seen in PHP, jumping from comprising 15% of open source vulnerabilities between 2009 to 2018 all the way up to 27% in 2019. This raises two questions. First, what is it about PHP that makes it apparently more vulnerable, and second, is do people still really use PHP anymore?

According to the TIOBE Index report in September 2019, PHP rose in popularity because of its ease of use for web designers with limited software development skills. The language appears to have traded security for ease of use, a compromise that is coming home to roost now that the community is getting better at uncovering vulnerabilities.

It is still used in popular applications like WordPress which are not going anywhere anytime soon. That said, trends show that PHP is in decline among developers in favor of more popular languages, like Python, that has been topping the lists for the past few years and has managed to keep its rate of vulnerabilities low.  

A Thousand Eyes are Ramping Up the Open Source Security Game

The third question is why are we seeing an increase in vulnerabilities for PHP now. While there are no proven answers here, we can look at trends in open source and application development for some sense of direction.

As more code is being developed, there is also increased review by the thousand eyes of the open source community. When we also consider the increased use of automated tools to help find more vulnerabilities, it’s easy to see why more issues are being discovered, fixed, and published. As open source security vulnerabilities become easier to directly report through GitHub Security Lab, the number of published vulnerabilities is going to continue to rise, especially in languages that have large code bases but might have previously escaped close scrutiny. 

Because of its significant use in open source projects like WordPress, and Drupal, there are a lot of PHP projects in use out there. They are now being reviewed by researchers who are finding vulnerabilities that might have always been present in the code, but simply had not yet been reported on.  

The Path Forward is with Better Coding Practices

At their core, security vulnerabilities are basically bugs that can expose an application and its data not only to failure but harm. When the coding error threatens the accessibility, integrity, or confidentiality of our data it falls into the realm of a security vulnerability. In most cases, these vulnerabilities are simply human error. As long as humans continue to write code, errors will happen and vulnerabilities will show up in our projects.

The question becomes what do we do to manage the vulnerabilities in the software that we use. First and foremost is that we need to teach and keep to best practices for secure coding. It is easy to say that someone’s coding is sloppy, but it is not enough to criticize. We need to get better.

Along with following best practices while coding, we need to also check our code for vulnerabilities, not only just before it is deployed. Few things are as painful as building a key part of your application on top of a dependency only to find that it has some serious vulnerabilities, thus forcing you to tear and replace in order to rework your code. If you understand the importance of testing for bugs at all stages of the Software Development Lifecycle, then the same ethos should hold true for checking for security vulnerabilities that can put you and your users at risk.

c++ ,github ,java (programming lang... ,java script ,open source ,open source security ,programming languages

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}