I am writing escape=false in my VF Page like this.

<apex:outputText escape="false" value="{!cr.Message__c}" rendered="{!(cr.Message__c)!= ''}"/><br/><br/>

The Mesage__c is a custom field in the object with is of type Rich Text Area. This issue is coming up in my checkmarx report. In the document I have checked using Rich text area eliminated XSS vulnerabilty. How do I solve this? I have tried all possible solutions like JSENCODE, HTMLENCODE etc. But the issue is still coming up in Checkmarx report.

  • Can it be an outputField rather than outputText? Then you don’t have to escape it?
    – Ranga
    Jun 21, 2018 at 6:53
  • It cant be used as outputField because its a part of wrapper class.
    – AJoshi
    Jun 21, 2018 at 6:59
  • @Ranga, Can you explain why apex:outputField will help in eliminating xss issue. I can change that and will explain to them
    – AJoshi
    Jun 22, 2018 at 5:38
  • All merge fields are always auto encoded if they don’t occur within escape =false. You don’t have to set escape =false if you use output field as it would handle html within it I believe. Here’s the link for more info developer.salesforce.com/page/…
    – Ranga
    Jun 22, 2018 at 6:39

1 Answer 1


The Salesforce database automatically scrubs rich text fields of all unsupported tags. The list of supported tags and attributes are found in the Rich Text Editor help. As such, this is probably a false positive. If this is part of an AppExchange app, you'll have to demonstrate that this really isn't an XSS issue (i.e. because there's no way unsafe content can possibly be saved in this field).

The scanner automatically flags all instances of escape="false" on any "tainted" input (e.g. any time data can be influenced by a user, it is considered unsafe). There really isn't any legitimate way to render a rich text area field without triggering a flag in the scanner, simply because it cannot detect the difference between a rich text field and a plain text field (which would definitely be a security vulnerability). Even if it could, I think it'd probably complain anyways, because someone could theoretically later change the data type and introduce a security vulnerability.

  • Thanks sfdcfox. I need to demonstrate this to Infosec guys. How do I show them or give a proof that this is a false positive.
    – AJoshi
    Jun 21, 2018 at 6:46
  • @AJoshi Actual technique may vary. Some guys are more paranoid than others. Show them the docs, demonstrate that you can't insert XSS-able strings, and hope it's enough. If not, you might end up having to scrap the idea, because there's no "safe" way to emit raw HTML according to the scanner; Salesforce automatically does two of the three things Checkmarx recommends, even if you disable the escaping feature (obviously, with escaping, Visualforce does all three for you).
    – sfdcfox
    Jun 21, 2018 at 7:02

You must log in to answer this question.

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