Take the 2-minute tour ×
Salesforce Stack Exchange is a question and answer site for Salesforce administrators, implementation experts, developers and anybody in-between. It's 100% free, no registration required.

We are currently looking into the best place to handle escaping (html encoding) when using VFRemoting.

It had been suggested to us that using always the option {escape: true} was the best approach from a security point of view as it avoids a cross site scripting vulnerability. From a development point of view this seems wrong or awkward because we build html5 and javascript (jquery / angular etc) rich client code which we think should handle the escaping.

It appears to us that most client side frameworks would handle the escaping so if the VFRemoting option was set to true then either double escaping would occur or additional effort would be required to handle escaped or unescape the content for the frameworks.

What is the best practise for using the escape option in JavaScript Remoting?

share|improve this question
    
welcome to salesforce.stackexchange Stefg. Choosing the right tags for your question will attract users with the right knowledge. Would you mind updating your question and attempt to find more related tags ? –  Samuel De Rycke Apr 16 at 9:19
2  
Thanks Samuel and user320, it seems that the tags have been updated by user320 already but I will make sure to add better tags in future posts. –  Stefg Apr 16 at 13:36

1 Answer 1

up vote 6 down vote accepted

what is the best place to handle escaping (html encoding) when using VF Remoting?

In your JavaScript framework, not in the transport. This is the responsibility of your template parser or output layer. With the huge diversity of application architectures and client-side frameworks, one truth isn't applicable to all uses of the VFRemoting client; some frameworks escape, some forget to.

I think it is exactly because of fragmentation around front-end frameworks, that Salesforce have defaulted the escaping up into the transport layer. They know the behaviour really doesn't belong there but it's for safety's sake! So they avail the escape parameter on RemoteAction invocations. This allows developers to make the right call under the right circumstances.

most client side frameworks would handle the escaping?

Yes! If one embraces a serious client-side stack like Sencha Ext, most content that reaches the presentation layer through bound components (eg grids) is escaped by default. As you note, doing this on the transport causes double escaping. To a purist, comms are the responsibility of the data layer (that means Stores and Proxies in Sencha) and it fully expects data on the wire NOT to be escaped.

Conversely, when using Salesforce's main MVC presentation layer (Visualforce and Apex). all content that reaches the page is already escaped by default. To get at unescaped content, you have to be very explicit by using apex:outputText element with escape=false attribute to get at unescaped content.

I see the difference as being: with VF+Apex we can't accidentally leave content unescaped. Whereas with Remoting and the client-side stack, it is easier for unescaped content to slip out by oversight alone.

what is the best practice for this?

Depends. From a best practises point of view, if one escapes universally (including when inappropriate) then developers will have to unescape the data manually before dealing with it anyway, which just reintroduces the problem with someone else to blame.

Definitely I appreciate the need for processes and procedures (eg escape by default) but legitimate exceptions exist. And if developers don't bother using the output layer of the framework it's all moot anyway ;-)

Underescaping is not without risk, even if it's an internal-only interface:

  • malicious users can plant code that leaks data, eg <img src="competitor.com/?track=...">
  • dirty data can break the app, eg United Oil & Gas <DOES NOT PAY INVOICES> (open tag!)

Overescaping is also not harmless:

  • an ampersand will expand to &amp&amp&amp&amp&amp;;;;; over time as a record gets saved
  • special characters in any field will gradually get dirtier and dirtier

Depends what you consider the lesser evil, and whether it pollutes your application architecture.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.