Skip to content

Add support for escaping values in templates#253

Merged
jashkenas merged 1 commit into
jashkenas:masterfrom
shesek:patch-1
Oct 5, 2011
Merged

Add support for escaping values in templates#253
jashkenas merged 1 commit into
jashkenas:masterfrom
shesek:patch-1

Conversation

@shesek

@shesek shesek commented Jul 20, 2011

Copy link
Copy Markdown
Contributor

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.

* Added support for auto-escaping of values using ```<%== ... %>```
@jzaefferer

Copy link
Copy Markdown

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.

@reconbot

reconbot commented Aug 4, 2011

Copy link
Copy Markdown

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.

@shesek

shesek commented Aug 5, 2011

Copy link
Copy Markdown
Contributor Author

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 <%= ... %>.

@paulyoder

Copy link
Copy Markdown

I would love to see this patch make it into underscore. I'm running into this issue on one of my current projects.

@jashkenas jashkenas merged commit 34f1046 into jashkenas:master Oct 5, 2011
@michaelficarra

Copy link
Copy Markdown
Collaborator

I think _.escape was a bad name. It should have been htmlEscape or htmlSpecialChars or something. Though I don't think it needed to be public in the first place...

@shesek

shesek commented Nov 9, 2011

Copy link
Copy Markdown
Contributor Author

@michaelficarra, yeah, those might be better names. However, it has to be stored globally somewhere to be accessible from the eval'd code used to create the template My bad - eval() does have access to the local scope. I never actually needed to use eval... must have misread something somewhere.

@shesek shesek deleted the patch-1 branch March 22, 2013 10:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants