💻 AppSec

ServiceNow API Security Configuration: Access Controls, ACLs, and Endpoint Hardening to Prevent Zero-Auth Exposure

The ServiceNow API breach highlights the risk of zero-auth API endpoint exposure in SaaS ITSM platforms. ServiceNow's platform provides granular access control mechanisms — ACLs, application scope policies, and API gateway controls — that, if properly configured, limit the blast radius of similar incidents. This guide covers the core security configuration for ServiceNow REST APIs.

4 min read
#servicenow#api-security#access-control#acl#itsm#saas-security#configuration#hardening

ServiceNow’s platform provides extensive configuration options for API endpoint security. The June 2026 incident — which exposed customer data via an unauthenticated API endpoint introduced in a platform update — is in part a consequence of insufficient validation of API access controls during platform upgrades. A well-configured ServiceNow instance has multiple independent layers of control that would limit the exposure from any single unauthenticated endpoint.

Layer 1: Global Authentication Policy

ServiceNow’s platform-level authentication settings control whether unauthenticated API access is possible at all.

Ensure Basic Authentication is disabled for REST APIs (unless explicitly required for service account integrations):

  • Navigate to: System Properties → Security
  • Set glide.http.allow_insecure_header_logins to false
  • Set glide.authenticate.session.required to true

Enable REST API authentication enforcement:

  • Navigate to: System Properties → REST API
  • Verify com.glide.restapi.require_auth is set to true — this ensures all REST API calls require authentication
  • Verify com.glide.security.allow_unauthenticated_access is set to false

These global settings establish a default-deny policy for unauthenticated API access. Platform updates that introduce new endpoints must overcome these settings to be accessible without authentication.

Layer 2: Access Control Lists (ACLs)

ServiceNow ACLs control which authenticated users can access specific tables, records, and operations. ACLs do not replace authentication requirements, but they enforce authorisation after authentication.

Audit ACLs on sensitive tables: Navigate to: Security → Access Control (ACL) and review ACLs for:

  • sys_user (user records) — verify that the read ACL requires a minimum role (not just “public”)
  • cmdb_ci (configuration items) — verify read requires appropriate CMDB read role
  • incident, change_request, problem — verify that external integration users have table-specific, not wildcard permissions

Check for overly permissive ACLs:

Navigate to Security → Access Control (ACL)
Filter: Operation = read, Role = public

Any ACL that allows “public” read access to sensitive tables is a misconfiguration that could amplify the impact of any future unauthenticated endpoint vulnerability.

Layer 3: Application Scope Isolation

ServiceNow’s application scoping system isolates custom applications and prevents them from accessing data outside their defined scope without explicit cross-scope access grants.

Review application scope access:

  • Navigate to: System Applications → Applications
  • For each custom application or integration scope, review whether cross-scope read access to sensitive tables has been granted
  • Remove any cross-scope access that is not actively required by a current integration

IP Address Allow-listing for service accounts: For integration accounts that use REST API with basic authentication, configure IP address restrictions:

  • Navigate to: User Administration → Users → <service account>
  • Set IP address restrictions on the service account to the source IPs of the integration system
  • This prevents service account credential compromise from being exploitable from arbitrary source IPs

Layer 4: API Gateway Controls

ServiceNow’s Integration Hub and Connection & Credential Aliases provide centrally managed credential storage and API gateway controls:

Mutual TLS for high-privilege integrations: For integrations that have access to sensitive ServiceNow data, require mutual TLS client certificate authentication in addition to standard credential-based authentication.

API rate limiting: Configure rate limiting for external API access — this does not prevent exploitation but limits data exfiltration volume in the event of a vulnerability.

OAuth 2.0 for third-party integrations: Replace basic authentication integrations with OAuth 2.0 where possible. OAuth tokens have defined expiry, can be revoked without password changes, and can be scoped to specific table access.

Post-Platform-Update Security Review Process

The June 2026 incident was introduced by a platform update. The standard mitigation is a post-upgrade security validation checklist:

  1. After every ServiceNow platform update, run an ACL audit comparing pre- and post-update public-accessible endpoints
  2. Review the platform release notes security section for any new API endpoints introduced in the release
  3. Test authenticated and unauthenticated access to new endpoints discovered in the release
  4. Verify that global authentication enforcement settings have not been changed by the update

ServiceNow publishes security notes with each platform release. These should be reviewed by the security team before applying the update to production, not after the incident.

Share this article