The description said the option allows user to determine whether to escape the Apex method’s response.

And, actually, it doesn't "escape" the respone, but "encode" or "not encode" the response.

Am I right?

When the remote action like this:

WebService static string showmsg(){
    return '<script>alert(\'Hello\')</script>';

With escape:false

showMsg() is <script>alert('Hello')</script>

With escape:true

showMsg() is &lt;script&gt;alert('Hello')&lt;/script&gt;

Just try difference characters, and find actually it only encode " => &QUOT; and < => &lt; and > => &rt;

And, it DOESN'T encode the two escape characters : ' and \


1 Answer 1


Yep. It is handling XML escape characters (& " < >), not JavaScript. But really, most non-trival applications will use escape: false and a client-side template system to do any escaping.

The default escape: true value is just a safety net to prevent XML code being dumped into the page inadvertently, for trivial applications which fail to escape their output.

Salesforce are pushing the escaping behaviour up into the transport layer by default. While it's not the right place, it's in the spirit of preventing unaware developers from leaving themselves vulnerable to client-side code injection (eg).

It's completely reasonable to have XML characters in the data (eg Grand Hotels & Resorts Ltd), and very standard front-end development practise to escape those XML characters before dumping output onto the page. Just not on the transport!

Obviously the Salesforce default behaviour will cause side effects if one intends to send XML tags around, eg via Rich Long Text fields, or any crazy server-side templating happening in a controller.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .