Secure languages & frameworks

Published: 2011-11-01
Last Updated: 2011-11-01 19:15:33 UTC
by Russ McRee (Version: 1)
6 comment(s)

Richard S wrote us and asked what information we could offer regarding languages & frameworks that are more suitable for developing secure applications, along with what attributes differentiate them over their less secure counterparts. 

I'll treat this as a starting point for a run on reader comments but will set the ground rules, and throw out some core elements to get the conversation under way.
In the interest of full disclosure, I am not a developer (good at break and assess but not create) and I work for Microsoft.
As such I recuse myself from all but a few strong convictions.
First, let's not go for the "this language is so much better than that language" or "that framework s**ks" approach. Instead, let's recognize that there are a wide variety of options and that the approach should be about secure development practices first and foremost.
Second, focus your comments and feedback on successes, with examples, while also not disclosing who you work for and the exact applications you refer to; in general terms, what works and why you believe your language/framework of choice is secure to the extent that it is.
Above all else, I espouse following an SDL/SDLC practice to include code review and threat modeling, as well as static and runtime analysis, with security checkpoints woven into to delivery schedules. I am of the opinion that this practice precedes the language or framework being used.
One can obviously write terrible code in the same language with which another developer can write the digital equivalent of Fort Knox.
As Swa Frantzen pointed out in a comment on the Critical Control 7 - Application Software Security diary he posted on my behalf, consider embracing "a bottom-up security framework such as OWASP ESAPI (Enterprise Security API).
OWASP ESAPI is available for Java EE, .NET, Classic ASP, PHP, while others are pending release (ColdFusion, C, C++).
Richard's line of questions is focused on web application development, and he posed the point that
there is much literature on design patterns & the importance of validation etc., but less on the  subject of secure languages and frameworks.
Again, I contend that this is a function less of there being one or two highly touted languages/frameworks, and more about those that have security-centric libraries to be leveraged for product hardening as well as good developers to do so. 
For your consideration (borrowed directly from Richard's inquiry):
1) If you take everything else being equal (defensively designed code with input validation, a hardened infrastructure, firewalls,  TLS, & so on) the question remains : how does  the choice of language & framework impact on the concept of security in depth?
2) What attributes of the language itself enhance security?
3) If "compiled" offers an advantage over "scripted" in this respect, do the likes of C#  have an advantage given the resources dedicated to supporting & securing it? Are compiled apps less vulnerable than scripted apps as a function of source code exposure post-compromise?
Also on the table are the challenges around 3rd party plugins for given platforms. I believe that this is always the soft spot in what may be otherwise splendid armor. Insert your favorite weakest link analogy here.
I believe a follow-up post will be required here to include references from industry studies that discuss:
  • Number of organizations that use each framework or language for 'secure'  applications
  • Availability & number of security elements built in to the core language / framework
  • Availability & number of 3rd party security elements built (can they be identified as trustworthy)
  • Number of vulnerabilities identified (per month, per year)   
  • Time to fix

So bring it on: tell us via the comment form what works for you and why (don't hesitate to include favorite static/runtime analysis tools).

Russ McRee Twitter




6 comment(s)


As a developer, I have always hated when other security experts refer to certain languages as more or less secure. The security of an app is almost entirely based on how good its code is. Certain languages attract developers with less skill, and thus apps developed in them tend to be more insecure. A seasoned developer should be able to write a secure app in any language.

Frameworks are a whole different story. Many are poorly maintained or have a lot of bad code. Few are developed with security as a main focus, as most feel that the key in this field is developing a method to generate apps in a fast and efficient matter. Clients would much rather disable security entirely than wait an extra day or go without a whizbang feature.

Personally, I have had great success using a framework for PHP called symfony ( There are many reasons to use symfony, but the important one for this blog post is that with the new version (Symfony2) the project raised funds and to undergo a full security audit by an outside firm. You can review the results here:

Does anyone know of other frameworks that have had a security audit?
Not strictly a framework, but
I think Mr. Glass nailed it. Too often "security frameworks" are seen as a way to make poor programmers produce "secure" code. How many times have we seen security bugs not in some library (say, a crypto library) but in the way some app uses the library.

If something can be called/used improperly or insecurely, it will be, by someone, somewhere. In a previous life, working as a software developer (mostly C and assembly) we used to joke that there were many people who could program but very few actual "programmers" (people who could actually write solid, secure, reliable, elegant code).
Brent, I agree with your comments - to a point.

So-called "Secure" frameworks/languages are not silver bullets, however, I think you shouldn't discount that a language/framework with better security fundamentals than average is at least a secure baseline for developers to start from - it's yours to lose; whereas a shoddy framework with poor security puts *all* the burden on the developer and potentially makes it a an uphill battle to produce even a modicum of security - you've essentially lost the battle out of the gate.
Jim Bird just posted on the SANS Software Security Blog with "real and useful security help for software developers." Lends nicely to this conversation.

Diary Archives