1

This might seem a question not related to this forum.

But, according to Salesforce Security reviews, we are not supposed to use innerHTML in our code. Since, this could cause Cross-Site-Scripting(XSS) issues as mentioned here: https://developer.salesforce.com/page/Secure_Coding_Cross_Site_Scripting

e.g., element.innerHTML = '<htmlcode>may be some script as well</htmlcode>';

Could you please suggest, how to replace the best way? Or, with function that is not unsupported by Salesforce

  • Can you provide any supporting documentation for your claim that innerHTML is not supported? Using html from jQuery would at least avoid using it directly, but it may still do so under the hood. – Adrian Larson Jan 22 '16 at 5:31
  • updated question with the link @AdrianLarson – San Tosh Jan 22 '16 at 5:35
  • Can you provide any additional detail about where your content is coming from? It may add helpful context. – Adrian Larson Jan 22 '16 at 18:14
2

I came up with a solution which might just work:

For static content:
- Use jQuery text method

For dynamic variables:
- Use javascript escape to escape any HTML content
- Use jQuery text method

For HTML content:
- Generate the DOM elements using document.createElement();
- Set the dynamic variables to be displayed on screen as text inside the DOM elements
- Set the attributes of DOM elements using attribute property after using Javascript escape

|improve this answer|||||
-2

Salesforce do not unsupported innerHtml but saying that it could be a way to attack your page.

If you can sanitize your string before adding it to DOM element, it is all okay.

You can do it by using escapeSingleQuotes on server side

Or you can also do like below:

{! SUBSTITUTE(SUBSTITUTE($Request.title,"<","<"),">",">")}

or you can also remove all unwanted active content before adding to dom using javascript as per your need.

I Hope this will help you.

|improve this answer|||||
  • 4
    This answer is completely wrong. escapeSingleQuotes is only for SOSL/SOQL where you're using dynamic queries. Also, your substitute won't fully prevent injection either client-side. – sfdcfox Jan 22 '16 at 6:20
  • 2
    For example, see this article here about the various dangers of simply replacing html arbitrarily without considering the consequences: owasp.org/index.php/…. Using innerHTML without serious consideration could break stuff. – sfdcfox Jan 22 '16 at 6:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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