Application Security Best Practice

5 min read

This article is based on the ServiceNow documentation article. See the original article on the ServiceNow doc site: ServiceNow HI: ServiceNow instance hardening | Security.

Escape XML #

Cross-site scripting occurs when an attacker injects malicious JavaScript into an entry point and the platform/application fails to escape the malicious JavaScript before transmitting it to the victim’s browser for execution. The glide.ui.escape_text property, when enabled, escapes the XML values at parser level before transmitting it to client’s browser. 

Escaping here means the following:

&  --> &

<  --> &lt;

>  --> &gt;

"  --> &quot;

'  --> &#x27;

/  --> &#x2F;

Example: <script>alert('XSS Attack');</script>

Escaping: &lt;script&gt;alert(&#39;XSS Attack&#39;);&lt;/script&gt;

 Click for more info…

SOAP Request Strict Security #

During SOAP web service calls/requests made against the tables to perform any CREATE, READ, UPDATE or DELETE operation, the glide.soap.strict_security property enforces web service security using a combination of basic authentication challenge/response over the HTTP protocol and system level access control using the Contextual Security

If this property is set to true, the following actions are performed:

  • Check incoming SOAP request for role authorization to validate if the user has appropriate role to perform the operation
  • Check the system-level ACLs while retrieving data in the form of SOAP data on the table
  • Check the field-level ACLs for any CRUD operation performed against a field of table

 Click for more info…

Escape Jelly #

The glide.ui.escape_all_script property, when set to true, forces all scripts injected in Jelly to be escaped by default. It escapes all the JS and HTML strings included within <j:jelly> ... </j:jelly> before being written to the output stream and prevents a number of XSS issues.

 Click for more info…

Escape HTML #

The system property glide.ui.escape_html_list_field escapes HTML for HTML fields in a list view. HTML is one of the types that can be assigned to the dictionary fields. Assigning “HTML” fields to any field type provides functionality to the user to format the content using HTML codes (for example, <p>,<a href>,<b>,<font>,<img> etc.). When you see the table list (for example, /problem_list.do) or view the list of records, these HTML formatted fields may appear if that column is selected in a list view and if this property is set to false.

A malicious user can inject HTML code within the form field to execute unwanted scripts on different client/user sessions. It is recommended to set this property to true so that HTML escaping is performed before the records/fields are rendered in the browser when the table is displayed as a list view. 

 Click for more info…

Client Generated Scripts Sandbox #

When set to true, the glide.script.use.sandbox property enables script sandboxing. This property belongs to the same family of 2.8 (glide.script.allow.ajaxevaluate) and 3.9 (glide.script.secure.ajaxgliderecord) that secures and restricts execution of scripts originating from the client.

There are two cases within the system that allow the client to send scripts to the server for evaluation:

  • Filters and/or queries: It is legal to send a filter to the server such as assigned_to=javascript:getMyGroups()
  • System API: The API call AJAXEvaluate allows the client to run arbitrary scripts on the server and receive a response

If you enable script sandboxing, the script being evaluated at either of these two entry points runs within a reduced rights sandbox with the following characteristics:

  • Only those business rules marked client callable are available within the sandbox
  • Only script includes marked client callable are available within the sandbox
  • Certain API calls (largely, but not entirely, limited to those dealing with direct DB access) are not allowed
  • Data cannot be inserted, updated, or deleted from within the sandbox – any calls to current.update(), for example, are ignored

If you run the system without script sandboxing enabled, none of these restrictions apply.  

 Click for more info…

Enable AJAXEvaluate #

The glide.script.allow.ajaxevaluate property belongs to the same family as 2.5 (glide.script.use.sandbox) and 3.9 (glide.script.secure.ajaxgliderecord), that secures and restricts execution of scripts originating from the client. There are two cases within the system that allow the client to send scripts to the server for evaluation:

  • Filters and/or queries: It is legal to send a filter to the server such as: assigned_to=javascript:getMyGroups().
  • System API: The API call AJAXEvaluate allows the client to run arbitrary scripts on the server and receive a response. 

When this property is set to false, the system does not allow the use of AJAXEvaluate API call from the client script.

 Click for more info…

Check UI Action Conditions Before Execution #

Checks conditions on UI actions before execution. When it is set to true, it will add an extra layer of validation using UI actions on the table before the form gets rendered in the browser.

 Click for more info…

Disabling SSLv2/SSLv3  #

When active, outbound connections from an instance are forced to use TLS instead of SSL. Setting this property forces the MID Server to use TLS when making outbound connections, such as REST and SOAP requests.

 Click for more info…

Updated on March 21, 2025