With programmers being human, there's a lot to be said for the framework providing a secure default. Even so, it's surprising how often this particular mistake occurs.
You seriously think developers will manually HTML encode every time user input is rendered in the response? It's not just HTML they have to worry about, but Javascript, URL, HTML attributes, etc. If the framework doesn't automatically do it, nobody does it. That is, until they get hit by XSS.
Depends on what you mean by "framework". I would interpret that as "the language in which you write your application", and in that case a language that treats text and HTML as different datatypes does provide more security.
Rails' conflation of these types guarantees that whatever the default for escaping, there will be bugs in applications written in/on rails.
Comments
Security shouldn't be a matter of the framework, especially if it belongs to well known problems like XSS.
With programmers being human, there's a lot to be said for the framework providing a secure default. Even so, it's surprising how often this particular mistake occurs.
You seriously think developers will manually HTML encode every time user input is rendered in the response? It's not just HTML they have to worry about, but Javascript, URL, HTML attributes, etc. If the framework doesn't automatically do it, nobody does it. That is, until they get hit by XSS.
Depends on what you mean by "framework". I would interpret that as "the language in which you write your application", and in that case a language that treats text and HTML as different datatypes does provide more security.
Rails' conflation of these types guarantees that whatever the default for escaping, there will be bugs in applications written in/on rails.
Of course. But there's no reason not to make security easier and more natural (pit of success vs. struggling uphill).