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.