RTE is shortening div tags



We use the source edit options (misctools) in an overlaid Rich Text Editor component.

It works well for the most part, however empty div tags are getting shortened, so:

<div class="some-data-class"></div>


<div class="some-data-class" />

This is breaking inclusion of dynamic markup via our javascript.

The div tag is not a void element, so I'm wondering why this is happening.

I've looked into settings for the RTE, but have yet to find a setting that would be related.

I think it may be related more to the XSS API. If I change the sightly display context to "unsafe" the issue goes away.

We cannot leave it in this context though as we need to ensure the XSS policy is enforced in all our RTEs.

Is there a XSS rule I can apply to prevent the shortening?

Accepted Solutions (1)

Accepted Solutions (1)



I figured out the issue,

The problem was caused by this line in the XSS policy:

<directive name="useXHTML" value="true" />

Per the OSASP documentation, this will output the sanitized data in XHTML format as opposed to just regular HTML:


Changing the value to "false" allows the sanitized markup to be output as standard HTML.

Block level elements are not shortened and made invalid.

Answers (3)

Answers (3)



Hi. Thank you for responding.

I'm already overlaying the xss policy configuration, as we have some custom attributes that need to be allowed in certain tags.

Note, this does not expose an instance to XSS attacks as the policy is still enforced.

When I view the error.log file while loading the page with this issue, I don't see any messages generated related to AntiSamy, or package org.apache.sling.xss.impl.HtmlToHtmlContentContext.

So either the issue is not caused by the XSS policy, or the Granite XSS API is only logging attribute filters and not tag/elements themselves.

Is there a XSS rule that would prevent a closing tag from being shortened?

Since divs are block level tags, this is not valid HTML:

<div class="some-data-class" />




Check the error.log for an error similar to [1].

If thats the case, You can overlay the "/libs/cq/xssprotection/config.xml" and update the security rules as per your business needs but that will expose AEM instance to cross-site scripting and not recommended by Adobe

For more details check [2]


25.02.2019 18:29:31.815 *INFO* [ [1551119371795] GET /content/support/en_US/security.html HTTP/1.1] org.apache.sling.xss.impl.HtmlToHtmlContentContext AntiSamy warning: The a tag contained an attribute that we could not process. The rel attribute had a value of "noopener noreferrer". This value could not be accepted for security reasons. We have chosen to remove this attribute from the tag and leave everything else in place so that we could process the input.

[2] https://helpx.adobe.com/ca/experience-manager/6-2/sites/developing/using/security.html