Web frameworks should be secure by default
March 5, 2012
In reaction to the recent GitHub Rails vulnerability, raganwald wrote in part (about the Rails security issue):
I understand why this view of insecure-by-default is popular, but it's making a fundamental mistake. The problem with the 'insecurity as a sharp tool' view is that insecurity is not like the other sharp tools in Rails' toolbox. When you misuse or misapply others of those sharp tools, you're very likely to find out right away because your webapp doesn't work right; things break, assuming that you actually test your features. You know that you've cut yourself and you need to fix it. With security issues, it's not at all obvious that you've just cut yourself on the edges of a sharp tool, because nothing obvious breaks or goes wrong. Security bugs are not like normal bugs; this is a large part of why they are hard to find.
(To extend the metaphor beyond the breaking point, default insecurity is not just a sharp tool, it is a sharp tool coated with an anti-coagulant and a numbing agent. Most people wouldn't want to work with such a thing.)
The real world argument for frameworks being secure by default is pragmatics. We pretty much know how most people develop web applications using frameworks; 90% or more of them do just enough to get their application working and tested (and many apps will not be fully tested, especially things like error paths). Only a very few people will go back and carefully audit their application for security issues (or probably even read your security documentation unless it's shoved in their face). If your framework ships as insecure by default, most of your developers will never notice and many of the web applications written in it will be insecure. This is not theoretical; as we've just seen with GitHub and Rails, it's what really happens, even with smart people and very good teams, and it happens over and over again. You cannot argue that people should be smarter and better than that, not if you are designing a framework for real people, because we know that they aren't.
(One fundamental reason it keeps happening is that security is almost always an overhead, not a selling feature. Teams are under relentless pressure to prioritize for features, because that's what people care about and can actually see. If they have to remember to do extra things for security, sooner or later those things are going to be overlooked in the rush to produce.)
Written on 05 March 2012.
* * *
Atom feeds are available; see the bottom of most pages.