glide.script.enforce_scope_checks_on_get_ref_record: cross-scope checks for getRefRecord() in ServiceNow Brazil

What the property does

getRefRecord() returns the record a reference field points to, for example current.assignment_group.getRefRecord(). If that record lives in a table of another application scope, the call crosses a scope boundary.

glide.script.enforce_scope_checks_on_get_ref_record decides whether cross-scope access checks apply to that call. The property record calls true the safe value: cross-scope access checks are enforced, an unauthorized call returns null and the platform logs an access violation. With false, the record calls it unsafe, no cross-scope check is made.

The property extends the dot-walking scope protections that came with Australia (KB2793170, Dot-Walk Scoping Security Enhancement). Those checks cover reading data through dot-walking across a reference field. This property closes the same gap for getRefRecord().

1. New Brazil instances: the property is true, so the checks are on from the start.
2. Upgraded instances: the property is false, so the behavior stays as it was before the upgrade until you change it.
3. Check the value on your own instance with the script under Check your instance. A sub-production instance cloned from production has the production value.

Assess and fix affected scripts

Scripts are at risk when they call getRefRecord() on a reference field whose target table belongs to a different application scope than the script, and that access is not authorized. Once the property is true, such a call returns null instead of the record. Code that uses the result without a null check then fails or silently skips its work.

The read-only script below lists server-side scripts that contain getRefRecord, with their table, name and scope. It is a starting point, not a full inventory: it does not cover every table that can hold a script.

1. Run the search script below on a sub-production instance and note every hit in a scoped application, plus global scripts that read records of scoped tables.
2. For each hit, check the scope of the referenced table. Calls that stay inside one scope are not affected by a cross-scope check.
3. Fix the access as described in KB3142985, and make sure the script handles a null result instead of assuming a record.
4. Look at the dot-walking checks from Australia at the same time. The same scripts often dot-walk across scopes as well, and the properties in the table below control those checks.

Read only: lists server-side scripts that call getRefRecord(), with their scope. Run it in System Definition > Scripts - Background.

// Read only: lists scripts that contain getRefRecord, with table, name and scope.
// Run in System Definition > Scripts - Background on a sub-production instance.
var sources = [
  ['sys_script_include', 'script'],
  ['sys_script', 'script'],
  ['sys_ui_action', 'script'],
  ['sysauto_script', 'script'],
  ['sys_script_fix', 'script'],
  ['sys_ws_operation', 'operation_script'],
  ['sp_widget', 'script'],
  ['sys_transform_script', 'script']
];
var total = 0;
for (var i = 0; i < sources.length; i++) {
  var table = sources[i][0], field = sources[i][1];
  if (!gs.tableExists(table)) continue;
  var gr = new GlideRecord(table);
  gr.addQuery(field, 'CONTAINS', 'getRefRecord');
  gr.query();
  while (gr.next()) {
    total++;
    gs.print(table + ' | ' + gr.getDisplayValue() + ' | scope: ' + gr.getDisplayValue('sys_scope') + ' | ' + gr.getUniqueValue());
  }
}
gs.print(total + ' script(s) found');

Enable the property

On an upgraded instance the property is false. Enabling it is a change of one value, so you can roll it back the same way.

1. Read KB3142985 and finish the assessment above on a sub-production instance.
2. Open sys_properties.list, filter on Name is glide.script.enforce_scope_checks_on_get_ref_record and set Value to true.
3. Run the affected scripts, flows and integrations and check the system log for access violations. Each one points to a getRefRecord() call that now returns null.
4. Fix what you find, then make the same change in production, ideally through an update set or your normal release process.
5. If something breaks in production, set the value back to false and fix the script on sub-production first.

Check your instance

Paste this read-only background script into System Definition > Scripts - Background on a sub-production instance. It prints the current value of every property in this guide. A property without a record runs on its platform default. You can also open sys_properties.list and filter by name.

// Read only: prints the current value of every property in this guide.
// Run in System Definition > Scripts - Background.
var names = [
  'glide.script.enforce_scope_checks_on_get_ref_record',
  'glide.script.dot_walk.enforce_cross_scope_access_all_tables',
  'glide.script.dot_walk.log_and_allow_violations',
  'glide.script.dot_walk.log_stack_trace_when_blocked',
  'glide.script.dot_walk.exempt_script_sources',
  'glide.script.dot_walk.add_attribute_on_table_create'
];
var found = {};
var gr = new GlideRecord('sys_properties');
gr.addQuery('name', 'IN', names.join(','));
gr.query();
while (gr.next()) {
  found[gr.getValue('name')] = gr.getValue('value');
}
for (var i = 0; i < names.length; i++) {
  var n = names[i];
  gs.print(n + ' = ' + (found.hasOwnProperty(n) ? found[n] : '(no record on this instance, platform default applies)'));
}

FAQ

Related