Best Practices for validating impact before setting glide.angular.legacy to false

[vv303332]

Hi Everyone, 
We have Health scan recommendation to change the glide.angular.legacy system property from true to false.

I have reviewed the official documentation and understand why ServiceNow recommends disabling the legacy AngularJS behavior security reasons .However ,i couldn't  find any official guidance describing the recommended validation or regression testing approach before  enabling the change

I have a few questions:
1) What testing needs to be performed before changing the this system property to false?
2)Have you observed any functional or upgrade - related issues after disabling the property?
3)is there any official ServiceNow KB or recommended regression test checklist for this change?
4) Did you identify and validate all the custom AngularJS components(Service portal widgets, UI pages, custom client side script etc.) before making the change?

[yashkamde]

Hello @vv303332 ,

1) If talk about testing every custom widget, UI pages using Angular directives (ng-*, $scope, angular.element). So test and check browser console for Angular errors, re-run ATF suites touching Service Portal.

2) Also I haven't seen upgrade issues caused directly by changing this property. The issues that do occur are almost always related to custom AngularJS implementations that depended on the legacy behavior rather than OOTB ServiceNow functionality.

3) As far as looked up, you can check this ServiceNow Client-Side JavaScript Library Patching - Security :

AngularJS Long Term Support 

4) In short if your instance has been heavily customized over the years, I would strongly recommend performing a complete inventory and regression test first, as there is no automated way to guarantee that all legacy AngularJS dependencies have been identified.

If my response helped mark as helpful and accept the solution.

[Abhishek Pal]

Hi @vv303332 ,

ServiceNow recommends setting glide.angular.legacy to false because this enables the patched AngularJS behavior. However, this should first be validated in a production-like sub-production instance.

The main documented functional impact is on custom AngularJS code, especially cross-domain JSONP requests. When the property is false, AngularJS sanitizeUri and $http security patches are applied, and existing cross-domain JSONP calls may fail.

Recommended validation approach:

1. Test in a production clone

Use a recently refreshed sub-production instance with the same:

- ServiceNow release and patch
- Store application versions
- Plugins
- Portal configuration
- Customizations

Do not make the initial change directly in production.

2. Inventory AngularJS customizations

Review custom records in areas such as:

- Service Portal widgets
- Angular Providers
- UI Scripts
- JavaScript Includes
- Portal themes
- UI Pages containing AngularJS
- Catalog Client Scripts
- Custom portal components and directives
- Third-party integrations called from portal client scripts

Search custom code for patterns such as:

$http.jsonp
method: 'JSONP'
JSON_CALLBACK
$http
$sanitize
$sce
trustAsResourceUrl
trustAsHtml
ng-bind-html
javascript:

Prioritize cloned OOB widgets and custom widgets that call external domains.

3. Establish a baseline

Before changing the property, test and document the current behavior for:

- Portal login and logout
- Public and authenticated pages
- Homepage and navigation menus
- Search and AI Search
- Catalog items
- Record producers
- Order guides
- Shopping cart and checkout
- Attachments
- Forms and reference fields
- Modals
- Custom widgets
- External links and embedded content
- CSM, HR, partner or custom portals
- Mobile browser behavior where applicable

Use ATF for repeatable scenarios and manually test the custom portal functionality that ATF does not cover.

4. Set the property to false in sub-production

Change:

glide.angular.legacy = false

Then log out, start a new browser session and repeat the regression tests.

5. Monitor the browser developer tools

Check the browser console and Network tab for:

- AngularJS errors
- Failed JSONP requests
- Blocked external URLs
- URLs prefixed with unsafe:
- HTTP 4xx or 5xx responses
- CORS or content-security errors
- Widgets that fail to render
- Links, images or resources that no longer load

6. Correct JSONP failures securely

If a legitimate cross-domain JSONP request fails, add only the required trusted domain to:

angular.jsonp.inclusion_list.urls

Keep:

angular.jsonp.inclusion_list.enabled = true

Do not set angular.jsonp.inclusion_list.enabled to false as a permanent workaround because that allows JSONP requests to any URL and reduces the security benefit.

Where possible, replace client-side JSONP integrations with a supported server-side REST integration. This is more secure and maintainable.

7. Run business regression testing

Ask the owners of each custom portal or AngularJS application to validate their critical user journeys.

Obtain sign-off from:

- Portal/application owners
- Security team
- ServiceNow platform team
- Integration owners
- Business testers

8. Production rollout

Deploy the change during a controlled change window.

Monitor:

- Client-side JavaScript errors
- Portal availability
- Integration failures
- User-reported issues
- Browser console errors
- ServiceNow logs

Keep a rollback plan to temporarily restore the property to true if a critical issue occurs. Any rollback should be treated as temporary because true retains the legacy behavior and associated security risk.

Expected impact:

OOB ServiceNow functionality on a supported release and patch should use supported platform behavior. The greatest risk is custom or third-party AngularJS implementation that depends on older unpatched behavior, particularly cross-domain JSONP and unsafe URL handling.

There is no single public ServiceNow regression checklist or automated scanner that guarantees all affected customizations will be identified. The recommended approach is a production-like clone, customization inventory, targeted code search, ATF coverage and business regression testing.

Official references:

Disable legacy AngularJS behavior:
https://www.servicenow.com/docs/r/platform-security/instance-security-hardening-settings/sc-legacy-a...

Available system properties:
https://www.servicenow.com/docs/r/platform-administration/r_AvailableSystemProperties.html

Restrict JSONP requests to trusted URLs:
https://www.servicenow.com/docs/r/platform-security/instance-security-hardening-settings/sc-restrict...

In summary, do not ignore the Health Scan recommendation, but do not apply it directly to production without testing. Set it to false in a production-like environment, focus testing on custom Service Portal and AngularJS code, remediate any JSONP or unsafe URL dependencies, and then promote the change through a controlled release.

Hope this helps!

If this response helped, please mark it as Helpful.
If it resolves your issue, please Accept it as Solution.

Kind Regards,
Abhishek Pal