Industry Observations-Technical Insight-Web Application Security

Relative Security of Programming Languages: Putting Assumptions to the Test

“In theory there is no difference between theory and practice. In practice there is.” – Yogi Berra

I like this quote because I think it sums up the way we as an industry all too often approach application security. We have our “best practices” and our conventional wisdom of how we think things operate, what we think is “secure” and standards that we think will constitute true security, in theory. However, in practice — in reality — all too often we find that what we think is wrong. We found this to be true when examining the relative security of popular programming languages, which is the topic of the WhiteHat Security 2014 Website Statistics Report that we launched today. The data we collected from the field defies the conventional wisdom we carry and pass down about the security of .Net, Java, ASP, Perl, and others.

The data that we derived in this report puts our beliefs around application security to the test by measuring how various web programming languages and development frameworks actually perform in the field. To which classes of attack are they most prone, how often and for how long? How do they fare against popular alternatives? Is it really true that the most popular modern languages and frameworks yield similar results in production websites?

By examining these questions and approaching their answers not with assumptions, but with hard evidence, our goal is to elevate conversations around how to “build-in” security from the start of the development process by picking a language and framework that not only solves business requirements, but security requirements as well.

For example, whereas one might assume that newer programming languages such as .Net or Java would be less prone to vulnerabilities, what we found was that there was not a huge difference between old languages and newer frameworks in terms of the average number of vulnerabilities. And when it comes to remediating vulnerabilities, contrary to what one might expect, legacy frameworks tended to have a higher rate of remediation – in fact, ColdFusion bested the whole field with an average remediation rate of almost 75% despite having been in existence for more than 20 years.

Similarly, many companies assume that secure coding is challenging because they have a ‘little bit of everything’ when it comes to the underlying languages used in building their applications. in our research, however, we found that not to be completely accurate. In most cases, organizations have a significant investment in one or two languages and very minimal investment in any others.

Our recommendations based on our findings? Don’t be content with assumptions. Remember, all your adversary needs is one vulnerability that they can exploit. Security and development teams must continue to measure their programs on an ongoing basis. Determine how many vulnerabilities you have and then how fast you should fix them. Don’t assume that your software development lifecycle is working just because you are doing a lot of things; anything measured tends to improve over time. This report can help serve as a real-world baseline to measure against your own.

To view the complete report, click here. I would also invite you to join the conversation on Twitter at #2014WebStats @whitehatsec.

  • Brad Wood

    “ColdFusion bested the whole field with an average remediation rate of almost 75% despite having been in existence for more than 20 years.”

    Really glad to see this kind of data come from the info sec community. I’m tired of people telling me CF is inherently more insecure than other languages.

  • Brad Wood

    Just finished reading the full report. Can you expand on how sites were selected for analysis? One glaring statistic I noticed was you show zero ColdFusion in use for Government, but govt is actually one of the hotspots of CF usage. There’s literally tons of CF in government. Also, you scored CF as having very low usage in energy and communications. This may be anecdotal, but my power company (KCP&L) uses CF, plus I know many people using CF who work for Sprint and AT&T locally. I’m curious how sites were selected and if only publicly accessible sites were taken into account, or if sites behind firewalls were counted too.