Add support for escaping values in templates#253
Conversation
* Added support for auto-escaping of values using ```<%== ... %>```
|
Encoding values should be the default, with an alternative tag for outputting unencoded values. If people have to opt-in to secure their applications, it doesn't happen. If they have to opt-out for the few cases where they don't want the encoding, they can make an actual decision to do so. As with accessbility, security works if its built-in and enabled by default. |
|
I tend to agree but that would be a major breaking api change. I wonder what the best way to introduce that would be? The underscore.js's escapeHTML function will protect you from text being treated as html tags but it's not necessarily safe to use to put in form values, or urls especially if the html is not properly formed. The safer way would be to assign the values as a javascript property instead of rendering it as HTML attributes. It is safer then not encoding the input at all. That being said I fully support this patch and would gladly take the api break in the future if we want to go that way. |
|
I think it might be okay to break backward compatibility, because you can easily change it back. Projects that breaks because of this could simply change the interpolate regex back to |
|
I would love to see this patch make it into underscore. I'm running into this issue on one of my current projects. |
|
I think |
|
@michaelficarra, yeah, those might be better names. |
To prevent XSS and to display values containing special characters properly, it would be nice to have a short syntax to automatically escape values.
This commit adds a new
<%== ... %>syntax that uses a new_.escape()function (taken from Backbone.js' escapeHTML). I'm not quite sure about that syntax, but I couldn't think of anything nicer.I actually think its better to escape values by default (with
<%= ... %>), as it should be done 90% of the time, and add some other syntax for adding raw HTML - but it'll break backward compatibility.