4 ms·
In this day and age, why don't most web frameworks consider security features to be a selling point? Revel, for example, doesn't mention it once on their front
by SkyMarshal 13y ago
In this day and age, why don't most web frameworks consider security features to be a selling point? Revel, for example, doesn't mention it once on their front page, and only 5 results in their Google Group when searching for "security" [1].
Is it just the case that speed - both of development and request/response performance - sells, and security is considered a solved problem, or something that should be implemented at the project level rather than framework level?
[1]: https://groups.google.com/forum/#!searchin/revel-framework/security https://groups.google.com/forum/#!searchin/revel-framework/s...
- j2labs 13y agoThe tendency to overlook concerns of security is not unique to web frameworks.
- Jormundir 13y agoBecause even if a web framework had a multitude of security features, there's still so much a developer can do with the framework that would introduce unforeseen security gaps. This somewhat makes it a liability to advertise security. The first security breach of a system built with the framework would completely undermine one of the differentiating features of the framework.
- tptacek 13y agoWhich security features are you thinking of? The only unmitigated successes I can think of are pretty standard and hard to market --- default XSS string tainting/quoting and CSRF protection.
- SkyMarshal 13y agoIdeally it would be nice to see a Security page with anything and everything related to security: - Security reporting SOP - CVE-IDs (not applicable w/ new projects obviously) - Links to documenation on methods of Authentication, Authorization, Access Control, etc - Details on any built-in countermeasures to applicable OWASP Top 10, and/or example implementation code for security-per-project frameworks Some partial examples, all easy to find a click or two away from the framework's home page: http://www.djangobook.com/en/2.0/chapter20.html http://www.djangobook.com/en/2.0/chapter20.html http://www.yiiframework.com/doc/guide/1.1/en/topics.security http://www.yiiframework.com/doc/guide/1.1/en/topics.security (docs page, but linked directly from Features list page) http://www.yiiframework.com/doc/guide/1.1/en/topics.auth http://www.yiiframework.com/doc/guide/1.1/en/topics.auth (docs page, but linked directly from Features list page) http://symfony.com/doc/current/contributing/code/security.html http://symfony.com/doc/current/contributing/code/security.ht... (more on their vulnerability reporting process, but nice to know their SOP) http://seventhings.liftweb.net/security http://seventhings.liftweb.net/security http://cakephp.org/ http://cakephp.org/ (not great but at least they pay some lip service to it on the home page, implying more details can be found digging around in the docs/source) http://www.springsource.org/features/security http://www.springsource.org/features/security (also not great but again, implying it can be found with some digging) This stuff may be SOP for mature frameworks, but would be nice to see it on new ones too.
- shadowfiend 13y agoLift explicitly mentions baked-in security as one of the seven things that sets it apart from most frameworks [1][2], because it's absolutely one of the most important aspects of it and any framework. The fact that it's not shouted from the rooftops (though it is on the front page) is something I'd rather like to change when I get a chance. [1] - http://liftweb.net http://liftweb.net [2] - http://seventhings.liftweb.net http://seventhings.liftweb.net