Closing the Secure Web Application Framework Manifesto Project

Last year we released a paper called the “The Secure Web Application Framework Manifesto” in the hopes of influencing web application framework developers to include more security features natively, or at least optionally, out-of-the box. Subsequently we made the paper into an OWASP project. Recently, Mark Curphey posted a blog entrycriticizing the state of OWASP and mentioning the Manifesto by name as a low quality project. I took some exception to his low quality categorization, but I also understood that he was speaking with experience when he said “you won’t get far” with the approach. We already had long term ambitions of working with the Django framework, but I decided to jump-start the process and ask the Django developers their thought about the manifesto project. Their response was that a monolithic document won’t change anything — if we want to help, we should just contribute to the project directly.

Mark was right. The Secure Web Application Framework Manifesto was the wrong approach.

As OWASP goes through a renaissance and several new initiatives start to take off, I think it’s an ideal time to close the manifesto project and take a different approach to advancing OWASP’s mission. Ultimately the goal of the manifesto project was to reduce application security pain for time-crunched developers. We were naïve, however, to expect that framework developers are willing to add a ton of new security features to their frameworks. In particular, we underestimated the aversion to feature bloat popular amongst many developers today.

We’ve changed course. I’ve recently moved away from application security consulting and back into product development — this time as a product owner — with an application based on Django. I get to work with a team of awesome developers. We’re going to help improve framework security by directly contributing code to Django. We’ll participate in Django discussion groups and point people to OWASP resources if & when application security concerns come up — particularly ESAPI for Python. In other words, rather than asking the Django community to come to the OWASP community we’ll go to them. In some cases, it won’t be possible to build the security features into the framework, but at least we can give people easy to integrate tools and appropriate instruction on how to use it. This is a natural progression of the ESAPI project and is a better use of our time than writing a monolithic set of static requirements.

Do you, like us, believe that improving the security and the frameworks and libraries that developers work from is a fundamental requirement to improving the state of application security? Do you believe that we need to simplify application security? Then advance the OWASP mission by contributing code or finding other ways get involved with an open source framework/library project team. Smart people like Jim Manico have been doing this for years — let’s follow their lead. For example, work with the Apache Xalan community to provide an option to turn off dangerous Java extensions for XSLTs by default so that WS-Security installations aren’t vulnerable to remote command execution out of the box. Add an optional JavaScript escaping attribute to the appropriate tags in your favorite tag library by leveraging ESAPI code. Add a configuration option to prevent session fixation in an authentication framework. The more we have security-minded people working in any one of these communities the better chance we have of building security in.

Previous Article
Mobile Security for the Forgetful
Mobile Security for the Forgetful

Are you interested in mobile application security? Max Veytsman, a security consultant at Security Compass,...

Next Article
5 Key Design Decisions That Affect Security in Web Applications
5 Key Design Decisions That Affect Security in Web Applications

Senior developers and architects often make decisions related to application performance or other areas tha...