How to prevent Cross Site Scripting (XSS) attack on your Adobe CQ based web application?
1 min read

How to prevent Cross Site Scripting (XSS) attack on your Adobe CQ based web application?

What is Cross Site Scripting (XSS)?

Cross Site Scripting (XSS) is a security weakness found in web apps. It occurs when the attackers are able to inject malicious contents or other client-side scripts into a website to bypass the control or change the output workflows of the application.
The acronym XSS uses to refer Cross Site Scripting instead of CSS, because CSS represents another popular web development term Cascading Style Sheet.

How to protect Adobe CQ/ AEM site from XSS?

Adobe CQ’s principal is, do not filter/encode the input, but always protect the user on output. Adobe CQ provides an XSSAPI based on Open Web Application Security Project (OWASP) AntiSamy Library. AntiSamy Java Library ensures that the user provided html, css or URL does not contain any malicious code.

Handling of the XSS from a product has been focused on AEM 5.6. The drawback of implementing XSS protection on the product has to call XSSAPI’s when developing codes, unlike regular web applications that protection layers implemented in the application server configuration.

However Adobe CQ by design doesn’t directly translate the user inputs into queries like SQL, so SQL injection is not possible in CQ as it doesn’t use any relational DB.

In AEM 6.0 the situation is different because of the new HTML template rendering tool Sightly, where all the request will go through the filter rather than developers call them into code.

The default configurations of AntiSamy library can be found in the file path below,

It is not recommended to implement your own encoding or filtering methods because XSS encoding is very difficult and hard to cover all the cases. So it’s better to use existing widely used libraries. If something is missing, report a bug.
But in case if you want to change anything in the configuration file, make a copy of the config.xml file at /apps/cq/xssprotection/config.xml. In that way, you can easily overlay the new changes without changing the default file.

XSSAPI example uses:

In Java class: