Java Web Frameworks Hodgepodge

Another rulepack release is behind us. On August 31st the latest version of the Fortify Secure Coding Rulepacks (English language, version 2009.3.0.0006) became available from update.fortify.com and the Fortify Customer Portal. The new release contains quite a few improvements, including: support for ColdFusion 7 and 8, enhanced PL/SQL support, as well as improvements to our handling of a number of Java web frameworks – Axis 1 and 2, GWT, JSF, and Struts 2. It’s this final subject, web frameworks, that I want to talk about in this post.

The thing that bothers me the most about web frameworks is that their numbers grow faster than anyone’s full understanding of their advantages, disadvantages, security holes, or simply capabilities. How many Java web frameworks can you think of? What about templating engines, which are becoming more and more popular and provide integration with various existing web frameworks? What about Ajax component libraries? Did you get JSF, Spring, Struts 1 and 2, WebWork, Apache Beehive, WebObjects, JBoss Seam, Facelets, FreeMarker, Velocity, RichFaces, and IceFaces?

The list goes on and on. And even though the end-goal is always the same – a web application that consists of model, view, and controller layers – each of the frameworks has its own way of achieving this goal and each claims to be an improvement over existing ones. While older frameworks, such as Struts 1, require action classes to extend an abstract base class, newer frameworks, such as Struts 2, allow any POJO to be used as an action. While JSF, Struts 2 and WebWork use configuration files to define beans and actions, JBoss Seam and Apache Beehive use annotations. While Facelets uses XHTML files to define templates, FreeMarker uses proprietary FTL files and Apache Velocity uses its own proprietary VM files. The list of differences goes on even longer than the list of frameworks.

What a headache it is for the developers to keep all these differences straight, especially when upgrading from an older framework to a newer one or migrating from one to another! Switching between different structures of various configuration files, learning to apply annotations where none used to be necessary, and implementing views with the new proprietary templating language seem like very error-prone processes. No wonder frameworks misuse is so common! And a security auditor at a company where programmers can choose any and all frameworks will have to know the ins and outs of a huge technology landscape. So, what can reduce frameworks misuse, and, for that matter, software bugs and flaws? I believe the answer is straightforward – standardization of web frameworks. The fewer differences there are among the frameworks, the easier it will be for the developers to adopt a new framework. The more frameworks are built according to an accepted standard, the easier it will be to establish a set of common guidelines and best practices around their usage. And once such guidelines are in place, they can be enforced. But until then we need ways to capture and apply knowledge about a large number of frameworks, and this is an area where static analysis becomes particularly useful.