Configuring Script sandbox property

  • Release version: Yokohama
  • Updated January 30, 2025
  • 2 minutes to read
    • Summarize
    Summarized using AI
    This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.

    Summary of Configuring Script sandbox property

    Theglide.script.use.sandboxsystem property controls whether client-generated scripts, such as those sent via filters, queries, or the AJAXEvaluate API, run inside a restricted sandbox environment on the server. This sandbox limits script capabilities to enhance security by reducing rights and restricting certain backend operations.

    Show full answer Show less

    By default, this property is enabled when the High Security Settings plugin is activated. It is not recommended to enable it independently outside of this plugin due to potential impact on script functionality and security considerations.

    Key Features

    • Scripts executed via filters or the AJAXEvaluate API run with reduced rights inside the sandbox.
    • Only business rules marked Client callable and script includes marked Sandbox enabled are accessible within this sandbox.
    • Direct database modification methods such as insert(), update(), and delete() are blocked, preventing data changes from sandboxed scripts.
    • Certain GlideSystem (gs) and ScopedGlideSystem methods related to messaging, logging, and workflow execution are restricted.
    • Starting from the Xanadu release, script includes must be explicitly marked as Sandbox enabled to be accessible inside the sandbox; the older Glide AJAX enabled (Client callable) flag is no longer sufficient.
    • When upgrading from Washington DC or earlier to Yokohama, script includes with the Client callable flag are automatically marked Sandbox enabled to maintain compatibility.

    Practical Implications for ServiceNow Customers

    • Enabling this property improves security by isolating client-generated scripts and restricting potentially unsafe operations.
    • Customers should ensure that only trusted, necessary business rules and script includes are marked Client callable or Sandbox enabled to control script access in the sandbox.
    • Scripts that attempt to modify records or use restricted methods will have those actions ignored or blocked, which may impact functionality if previously allowed.
    • Logging methods can be selectively enabled or disabled in the sandbox using the glide.security.sandboxnologging property.
    • Understanding which methods are restricted helps in debugging and designing scripts that run successfully within the sandbox constraints.

    Key Outcomes

    • Enhanced instance security by running client-generated scripts in a controlled, reduced-rights environment.
    • Prevention of unauthorized data modifications and restricted API usage from client-initiated scripts.
    • Clear governance on which scripts and APIs are permitted in sandboxed execution, aiding compliance and risk management.
    • Maintained backward compatibility during upgrades via automatic flag adjustments for script includes.

    Enable the script sandbox property (glide.script.use.sandbox) to run client-generated scripts inside a sandbox that has restricted rights.

    Note:
    This property is enabled by default when you activate the High Security Settings plugin. Don’t enable this property outside of the plugin.

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

    • Filters or queries: It’s 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 the script sandbox property (glide.script.use.sandbox), the script being evaluated via 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 Sandbox enabled are available within the sandbox.
    • Certain API calls (largely but not entirely limited to those dealing with direct DB access) aren’t allowed.
    • Data can’t be inserted, updated, or deleted from within the sandbox. Any calls to current.update(), for example, are ignored.
    Note:
    Beginning with the Xanadu release, script includes marked as Glide AJAX enabled (previously named Client callable) aren’t accessible within the sandbox. Only those marked Sandbox enabled are available within the sandbox. When upgrading to the Yokohama release from the Washington DC release or earlier, any script includes marked as Client callable are also marked as Sandbox enabled.
    Property Description
    glide.script.use.sandbox Run client-generated scripts (AJAXEvaluate and query conditions) inside a reduced-rights "sandbox."

    If true, only those business rules with the Client callable option selected and script includes with the Sandbox enabled option selected are available and certain back-end API calls are disallowed.

    Restricted methods with sandbox enabled

    These methods aren’t supported in client-generated scripts when script sandboxing is enabled.

    Note:
    The GlideSystem (gs) methods log(), logError(), and logWarning() can be enabled with script sandboxing by setting the glide.security.sandbox_no_logging system property to false.

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

    Table 1. Restricted methods
    Class Method
    GlideRecord
    • deleteMultiple()
    • deleteRecord()
    • getRowCount()
    • insert()
    • update()
    • updateMultiple()
    GlideSystem (gs)
    • addErrorMessage()
    • addInfoMessage()
    • addMessage()
    • eventQueue()
    • flushMessages()
    • getEscapedProperty()
    • getProperty()
    • log()
    • logError()
    • logWarning()
    • setProperty()
    • setRedirect()
    • setReturn()
    • workflowFlush()
    ScopedGlideRecord
    • deleteMultiple()
    • deleteRecord()
    • insert()
    • update()
    • updateMultiple()
    ScopedGlideSystem (gs)
    • addErrorMessage()
    • addInfoMessage()
    • debug()
    • eventQueue()
    • executeNow()
    • getProperty()
    • getSessionToken()
    • info()
    • setRedirect()
    GlideDate

    GlideDateTime

    GlideTime
    • add()
    • addDays()
    • addDaysLocalTime()
    • addDaysUTC()
    • addMonthsLocalTime()
    • addMonths()
    • addSeconds()
    • addWeeks()
    • addYears()
    • compareTo()
    • getByFormat()
    • getDate()
    • getDayOfWeek()
    • getDayOfWeekUTC
    • getDayOfWeekLocalTime()
    • getDayOfMonth()
    • getDayOfMonthLocalTime()
    • getDayOfMonthNoTZ()
    • getDayOfWeek()
    • getDayOfWeekLocalTime()
    • getDayOfWeekUTC()
    • getHourOfDayLocalTime()
    • getHourOfDayUTC()
    • getDaysInMonth()
    • getDaysInMonthUTC()
    • getDaysInMonthLocalTime()
    • getDisplayValueInternal()
    • getDisplayValue()
    • getHourLocalTime()
    • getLocalDate()
    • getLocalTime()
    • getMinutesLocalTime()
    • getMinutesUTC()
    • getMonthLocalTime()
    • getMonthNoTZ()
    • getMonthUTC()
    • getNumericValue()
    • getSeconds()
    • getTime()
    • getTZOffset()
    • getValue()
    • getYear()
    • getUserTimeZone()
    • getWeekOfYearLocalTime()
    • getWeekOfYearUTC()
    • getYearUTC()
    • getYearLocalTime()
    • isDST()
    • onOrAfter()
    • onOrBefore()
    • setDayOfMonthUTC()
    • setDisplayValue()
    • setMonth()
    • setNumericValue()
    • setTZ()
    • setValue()
    • setValueUTC()
    • subtract()
    • toString()
    GlideSchedule
    • add()
    • isInSchedule()
    • Load()
    • whenNext()