XML cross-site scripting check

Last published : Sep 22, 2026
The XML Cross-Site Scripting check examines the user requests for possible cross-site scripting attacks in the XML payload. If it finds a possible cross-site scripting attack, it blocks the request.
To prevent misuse of the scripts on your protected web services to breach security on your web services, the XML Cross-Site Scripting check blocks scripts that violate the same origin rule, which states that scripts must not access or modify content on any server but the server on which they are located. Any script that violates the same origin rule is called a cross-site script, and the practice of using scripts to access or modify content on another server is called cross-site scripting. The reason cross-site scripting is a security issue is that a web server that allows cross-site scripting can be attacked with a script that is not on that web server, but on a different web server, such as one owned and controlled by the attacker.
The Web App Firewall offers various action options for implementing XML Cross-Site Scripting protection. You have the option to configure Block, Log, and Stats actions.
The Web App Firewall XML cross-site scripting check is performed on the payload of the incoming requests and attack strings are identified even if they are spread over multiple lines. The check looks for cross-site scripting attack strings in the element and the attribute values. You can apply relaxations to bypass security check inspection under specified conditions. The logs and statistics can help you identify needed relaxations.
The CDATA section of the XML payload might be an attractive area of focus for the hackers because the scripts are not executable outside the CDATA section. A CDATA section is used for content that is to be treated entirely as character data. HTML mark up tag delimiters <, >, and /> will not cause the parser to interpret the code as HTML elements. The following example shows a CDATA Section with cross-site scripting attack string:
<![CDATA[rn
<script language="Javascript" type="text/javascript">alert ("Got you")</script>rn
]]>
Related information

Action Options

An action is applied when the XML Cross-Site Scripting check detects an cross-site scripting attack in the request. The following options are available for optimizing XML Cross-Site Scripting protection for your application:
  • Block—Block action is triggered if the cross-site scripting tags are detected in the request.
  • Log—Generate log messages indicating the actions taken by the XML Cross-Site Scripting check. If block is disabled, a separate log message is generated for each location (ELEMENT, ATTRIBUTE) in which the cross-site scripting violation is detected. However, only one message is generated when the request is blocked. You can monitor the logs to determine whether responses to legitimate requests are getting blocked. A large increase in the number of log messages can indicate attempts to launch an attack.
  • Stats—Gather statistics about violations and logs. An unexpected surge in the stats counter might indicate that your application is under attack. If legitimate requests are getting blocked, you might have to revisit the configuration to see if you need to configure new relaxation rules or modify the existing ones.

Relaxation Rules

If your application requires you to bypass the Cross-Site Scripting check for a specific ELEMENT or ATTRIBUTE in the XML payload, you can configure a relaxation rule. The XML Cross-Site Scripting check relaxation rules have the following parameters:
  • Name—You can use literal strings or regular expressions to configure the name of the ELEMENT or the Attribute. The following expression exempts all ELEMENTS beginning with the string name_ followed by a string of uppercase or lowercase letters, or numbers, that is at least two and no more than fifteen characters long:
    \^name_[0-9A-Za-z]{2,15}$
Note
The names are case sensitive. Duplicate entries are not allowed, but you can use capitalization of the names and differences in location to create similar entries. For example, each of the following relaxation rules is unique:
  1. XMLcross-site scripting: ABC IsRegex: NOTREGEX Location: ATTRIBUTE State: ENABLED
  2. XMLcross-site scripting: ABC IsRegex: NOTREGEX Location: ELEMENT State: ENABLED
  3. XMLcross-site scripting: abc IsRegex: NOTREGEX Location: ELEMENT State: ENABLED
  4. XMLcross-site scripting: abc IsRegex: NOTREGEX Location: ATTRIBUTE State: ENABLED
  • Location—You can specify the Location of the Cross-site Scripting Check exception in your XML payload. The option ELEMENT is selected by default. You can change it to ATTRIBUTE.
  • Comment—This is an optional field. You can use up to a 255 character string to describe the purpose of this relaxation Rule.
Warning
Regular expressions are powerful. Especially if you are not thoroughly familiar with PCRE-format regular expressions, double-check any regular expressions you write. Make sure that they define exactly the name that you want to add as an exception, and nothing else. Careless use of Regular Expressions can have results that you do not want, such as blocking access to web content that you did not intend to block or allowing an attack that the XML Cross-Site Scripting check would otherwise have blocked.

Using the Command Line to Configure the XML Cross-Site Scripting check

To configure XML Cross-Site Scripting check actions and other parameters by using the command line
If you use the command-line interface, you can enter the following commands to configure the XML Cross-Site Scripting Check:
> set appfw profile <name> -XMLcross-site scriptingAction (([block] [log] [stats]) | [none])
To configure a XML Cross-Site Scripting check relaxation rule by using the command line
You can add relaxation rules to bypass inspection of cross-site scripting script attack inspection in a specific location. Use the bind or unbind command to add or delete the relaxation rule binding, as follows:
> bind appfw profile <name> -XMLcross-site scripting <string> [isRegex (REGEX | NOTREGEX)] [-location ( ELEMENT | ATTRIBUTE )] –comment <string> [-state ( ENABLED | DISABLED )]
> unbind appfw profile <name> -XMLcross-site scripting <String>
Example:
> bind appfw profile test_pr -XMLcross-site scripting ABC
After executing the above command, the following relaxation rule is configured. The rule is enabled, the name is treated as a literal (NOTREGEX), and ELEMENT is selected as the default location:
1)      XMLcross-site scripting:  ABC             IsRegex:  NOTREGEX

        Location:  ELEMENT       State:  ENABLED

`> unbind appfw profile test_pr -XMLcross-site scripting abc`

ERROR: No such XMLcross-site scripting check

`> unbind appfw profile test_pr -XMLcross-site scripting ABC`

 Done

Using the GUI to configure the XML Cross-Site scripting check

In the GUI, you can configure the XML Cross-Site scripting check in the pane for the profile associated with your application.
To configure or modify the XML Cross-Site Scripting check by using the GUI
  1. Navigate to Web App Firewall > Profiles, highlight the target profile, and click Edit.
  2. In the Advanced Settings pane, click Security Checks.
The security check table displays the currently configured action settings for all the security checks. You have 2 options for configuration:
a) If you just want to enable or disable Block, Log, and Stats actions for the XML Cross-Site Scripting check, you can select or clear check boxes in the table, click OK, and then click Save and Close to close the Security Check pane.
b) You can double click XML Cross-Site Scripting, or select the row and click Action Settings, to display the action options. After changing any of the action settings, click OK to save the changes and return to the Security Checks table.
You can proceed to configure other security checks if needed. Click OK to save all the changes you have made in the Security Checks section, and then click Save and Close to close the Security Check pane.
To configure a XML Cross-Site Scripting relaxation rule by using the GUI
  1. Navigate to Web App Firewall > Profiles, highlight the target profile, and click Edit.
  2. In the Advanced Settings pane, click Relaxation Rules.
  3. In the Relaxation Rules table, double-click the XML Cross-Site Scripting entry, or select it and click Edit.
  4. In the XML Cross-Site Scripting Relaxation Rules dialogue box, perform Add, Edit, Delete, Enable, or Disable operations for relaxation rules.
To manage XML Cross-Site Scripting relaxation rules by using the visualizer
For a consolidated view of all the relaxation rules, you can highlight the XML Cross-Site Scripting row in the Relaxation Rules table, and click Visualizer. The visualizer for deployed relaxations offers you the option to Add a new rule or Edit an existing one. You can also Enable or Disable a group of rules by selecting a node and clicking the corresponding buttons in the relaxation visualizer.
To view or customize the Cross-Site Scripting patterns by using the GUI
You can use the GUI to view or customize the default list of cross-site scripting allowed attributes or allowed tags. You can also view or customize the default list of cross-site scripting denied Patterns.
The default lists are specified in Web App Firewall > Signatures > Default Signatures. If you do not bind any signature object to your profile, the default cross-site scripting Allowed and Denied list specified in the Default Signatures object will be used by the profile for the Cross-Site Scripting security check processing. The Tags, Attributes, and Patterns, specified in the default signatures object, are read-only. You cannot edit or modify them. If you want to modify or change these, make a copy of the Default Signatures object to create a User-Defined signature object. Make changes in the Allowed or Denied lists in the new user-defined signature object and use this signature object in the profile that is processing the traffic for which you want to use these customized allowed and denied lists.
For more information about signatures, see <http://support.citrix.com/proddocs/topic/ns-security-10-map/appfw-signatures-con.html>.
To view default cross-site scripting patterns:
  1. Navigate to Web App Firewall > Signatures, select *Default Signatures, and click Edit. Then click Manage SQL/cross-site scripting Patterns.
The Manage SQL/cross-site scripting Paths table shows following three rows pertaining to cross-site scripting :
           xss/allowed/attribute

           xss/allowed/tag

           xss/denied/pattern
Select a row and click Manage Elements to display the corresponding cross-site scripting Elements (Tag, Attribute, Pattern) used by the Web App Firewall Cross-Site Scripting check.
To customize cross-site scripting Elements: You can edit the user-defined signature object to customize the allowed Tag, allowed Attributes and denied Patterns. You can add new entries or remove the existing ones.
  1. Navigate to Web App Firewall > Signatures, highlight the target user-defined signature, and click Edit. Click Manage SQL/cross-site scripting Patterns to display the Manage SQL/cross-site scripting paths table.
  2. Select the target cross-site scripting row.
a) Click Manage Elements, to Add, Edit or Remove the corresponding cross-site scripting element.
b) Click Remove to remove the selected row.
Warning
Be very careful when you remove or modify any default cross-site scripting element, or delete the cross-site scripting path to remove the entire row. The signatures, HTML Cross-Site Scripting security check, and XML Cross-Site Scripting security check rely on these Elements for detecting attacks to protect your applications. Customizing the cross-site scripting Elements can make your application vulnerable to Cross-Site Scripting attacks if the required pattern is removed during editing.

Using the log feature with the XML cross-site scripting check

When the log action is enabled, the XML Cross-Site Scripting security check violations are logged in the audit log as APPFW_XML_cross-site scripting violations. The Web App Firewall supports both Native and CEF log formats. You can also send the logs to a remote syslog server.
To access the log messages by using the command line
Switch to the shell and tail the ns.logs in the /var/log/ folder to access the log messages pertaining to the XML Cross-Site Scripting violations:
> **Shell**

> **tail -f /var/log/ns.log | grep APPFW_XML_cross-site scripting**
Example of a XML Cross-Site Scripting security check violation log message in Native log format showing <blocked> action
Oct  7 01:44:34 <local0.warn> 10.217.31.98 10/07/2015:01:44:34 GMT ns 0-PPE-1 : default APPFW APPFW_XML_cross-site scripting 1154 0 :  10.217.253.69 3466-PPE1 - owa_profile http://10.217.31.101/FFC/login.html Cross-site script check failed for field script="Bad tag: script" <**blocked**>
Example of a XML Cross-Site Scripting security check violation log message in CEF log format showing <not blocked> action
Oct  7 01:46:52 <local0.warn> 10.217.31.98 CEF:0|Citrix|NetScaler|NS11.0|APPFW|APPFW_XML_cross-site scripting|4|src=10.217.30.17 geolocation=Unknown spt=33141 method=GET request=http://10.217.31.101/FFC/login.html msg=Cross-site script check failed for field script="Bad tag: script" cn1=1607 cn2=3538 cs1=owa_profile cs2=PPE0 cs4=ERROR cs5=2015 act=**not blocked**
To access the log messages by using the GUI
The GUI includes a useful tool (Syslog Viewer) for analyzing the log messages. You have multiple options for accessing the Syslog Viewer:
  • Navigate to the Web App Firewall > Profiles, select the target profile, and click Security Checks. Highlight the XML Cross-Site Scripting row and click Logs. When you access the logs directly from the XML Cross-Site Scripting check of the profile, the GUI filters out the log messages and displays only the logs pertaining to these security check violations.
  • You can also access the Syslog Viewer by navigating to NetScaler > System > Auditing. In the Audit Messages section, click the Syslog messages link to display the Syslog Viewer, which displays all log messages, including other security check violation logs. This is useful for debugging when multiple security check violations might be triggered during request processing.
  • Navigate to Web App Firewall > policies > Auditing. In the Audit Messages section, click the Syslog messages link to display the Syslog Viewer, which displays all log messages, including other security check violation logs.
The XML based Syslog Viewer provides various filter options for selecting only the log messages that are of interest to you. To select log messages for the XML Cross-Site Scripting check, filter by selecting APPFW in the dropdown options for Module. The Event Type list offers a rich set of options to further refine your selection. For example, if you select the APPFW_XML_cross-site scripting check box and click the Apply button, only log messages pertaining to the XML Cross-Site Scripting security check violations appear in the Syslog Viewer.
If you place the cursor in the row for a specific log message, multiple options, such as Module, Event Type, Event ID, Client IP and so forth. appear below the log message. You can select any of these options to highlight the corresponding information in the log message.

Statistics for the XML cross-site scripting violations

When the stats action is enabled, the counter for the XML Cross-Site Scripting check is incremented when the Web App Firewall takes any action for this security check. The statistics are collected for Rate and Total count for Traffic, Violations, and Logs. The size of an increment of the log counter can vary depending on the configured settings. For example, if the block action is enabled, a request for a page that contains three XML Cross-Site Scripting violations increments the stats counter by one, because the page is blocked as soon as the first violation is detected. However, if block is disabled, processing the same request increments the statistics counter for violations and the logs by three, because each violation generates a separate log message.
To display XML Cross-Site Scripting check statistics by using the command line
At the command prompt, type:
> **sh appfw stats**
To display stats for a specific profile, use the following command:
> **stat appfw profile** <profile name>
To display XML Cross-Site Scripting statistics by using the GUI
  1. Navigate to System > Security > Web App Firewall.
  2. In the right pane, access the Statistics Link.
  3. Use the scroll bar to view the statistics about XML Cross-Site Scripting violations and logs. The statistics table provides real-time data and is updated every 7 seconds.