How effective are the application frameworks that offer security support for developers?
There is no replacement for all developers having at least some knowledge of secure design and coding principles.
In terms of security support, current frameworks do provide some value, but there is still much work to be done to eliminate vulnerabilities such as SQL injection, cross-site scripting (XSS) and cross-site request forgery (CSRF).
At the current time, development frameworks at best support the creation of secure code, but they do not prevent the creation of insecure code. That means developers who understand the framework and the security facilities that are available are in a better position to create secure code. But developers with little understanding of secure coding practices in general -- and the security capabilities of the framework in particular -- can still introduce common vulnerabilities into applications.
On a per-vulnerability basis, here are some of the facilities that exist in commonly used frameworks that introduce security issues:
- SQL injection. Object to relational mapping (ORM) libraries such as Hibernate can provide some protection against SQL injection vulnerabilities by abstracting the developer away from direct manipulation of database queries. However, most ORM libraries allow developers to create free-form queries, which still leaves the application open to injection attacks.
- Cross-site scripting (XSS). The .NET framework provides some out-of-the-box XSS protection accessible via the ValidateRequest attribute. This is helpful, but since it relies on a blacklist of known bad payloads, it can be bypassed. So developers still need to properly encode data to protect it from XSS vulnerabilities.
- Cross-site request forgery. The latest version of the Tomcat servlet container has a CSRF prevention filter that offers protection against many CSRF attacks.
This is a brief list of frameworks and countermeasures, but the reality is that for most development platforms there is not a great set of standard tools and libraries that prevent the introduction of common classes of vulnerabilities. Also, many developers are not aware of the available resources and how to use them correctly. Finally, the availability of the standard platform APIs to create database queries or Web page content allows developers to simply write to these APIs and introduce vulnerabilities into their applications.
One interesting development in this space is the playdoh project from Mozilla. Playdoh is a Web application template based on the Django Python Web application framework. Developers building applications in Playdoh have access to all of Django's security facilities as well as some additional secure-by-default libraries and settings. Playdoh is still a relatively new project and Django is not as common in many corporate environments when compared to Java Enterprise Edition (JEE) or ASP.NET, but Django's approach is promising.
In the future, perhaps other platforms will take a similar comprehensive and secure-by-default model for secure coding. That said, while frameworks have a place in helping teams create applications free of common vulnerabilities, there is no replacement for all developers having at least some knowledge of secure design and coding principles.
Dig Deeper on Topics Archive
Related Q&A from Dan Cornell
Is it safe to move from on-premises application lifecycle management tools to cloud-based tools? Read this expert answer to find out. Continue Reading
Can security impact application performance? What security vulnerabilities might be slowing us down? Continue Reading
As our developers incorporate more and more third-party software components and partner APIs that we don't have direct control over, how do we test ... Continue Reading