ServiceNow Security Assessment: Auditing API Exposure and Access Control Configuration

The ServiceNow API breach this week exposes a gap in how organisations assess the security posture of their SaaS ITSM platforms. Unlike enterprise applications running on-premises, SaaS platforms are commonly excluded from periodic vulnerability assessments — the reasoning being that the vendor manages the underlying infrastructure. What the ServiceNow incident demonstrates is that platform-level vulnerabilities are a vendor responsibility, but instance-level configuration is entirely a customer responsibility.

This assessment guide covers the key security checks for ServiceNow instances that can be performed using the platform’s built-in administrative tools, without requiring external scanning infrastructure.

Pre-Assessment: Scope Definition

Before beginning the assessment, define the scope clearly:

In scope:

• ServiceNow instance authentication configuration
• REST API endpoint exposure and authentication requirements
• ACL configuration on sensitive tables
• Service account privilege scope and access restrictions
• Integration credential storage practices
• Audit log coverage

Out of scope (vendor responsibility):

• Underlying platform infrastructure security
• ServiceNow data centre network controls
• ServiceNow’s software development and patching process

Check 1: Authentication Bypass Exposure Assessment

The most critical check following the June 2026 incident is verifying that no unauthenticated access to the instance API is possible.

Test unauthenticated REST API access:

From a machine not authenticated to ServiceNow, attempt REST API queries against the instance:

GET https://<instance>.service-now.com/api/now/table/sys_user?sysparm_limit=1

The response should be a 401 Unauthorized. If the response returns JSON data, the instance has an unauthenticated access path that must be immediately escalated.

Verify authentication enforcement system property:

In the ServiceNow admin console, navigate to: System Properties → Security

Check:

• glide.authenticate.session.required = true
• glide.http.allow_insecure_header_logins = false

If either of these is not set to the secure value, document and remediate immediately.

Check 2: Public ACL Inventory

ACLs with a “public” role (meaning no authentication or role required) are the configuration pattern that amplifies the impact of any authentication bypass vulnerability.

Query for public read ACLs:

Navigate to: Security → Access Control (ACL)

Filter conditions:

• Operation = read
• Role = public (or role field is empty)

Review the resulting list. Some public read ACLs are legitimate (publicly accessible knowledge base articles, the login page, certain UI pages). Flag any public read ACLs on:

• sys_user — user records
• cmdb_ci — configuration items
• incident — incident tickets
• change_request — change records
• sc_req_item — service catalogue requests
• Any custom table that may contain sensitive data

For each flagged ACL, determine whether it is intentional (has a documented business justification) or misconfigured. Remediate unintentional public read access by adding the minimum required role.

Check 3: Service Account Privilege Audit

Service accounts used for integrations commonly accumulate privileges over time. A periodic review identifies service accounts with broader access than their integration requires.

Inventory service accounts:

Navigate to: User Administration → Users Filter: Type = service_account (or identify service accounts by naming convention)

For each service account, record:

1. The integration it serves (document in a spreadsheet)
2. The roles assigned
3. Whether an IP address restriction is configured
4. Last login date

Flag for remediation:

• Service accounts with admin or security_admin roles (rarely required for integrations)
• Service accounts with no IP address restriction that access the API from external IPs
• Service accounts with no activity in the past 90 days (likely stale integrations)
• Service accounts whose roles do not match the stated integration purpose

Check 4: Credential Storage Assessment

Credentials stored in ServiceNow — whether in the Credential Management module or informally in ticket fields — represent a specific risk if an API breach occurs.

Formal credential storage (Credential Management):

Navigate to: Connections & Credentials → Credentials

List all stored credentials. For each:

• Verify the credential is still in active use by a current integration
• Remove stale credentials from retired integrations
• Confirm that credential field values are encrypted at rest (ServiceNow encrypts credentials in the Credential Management module by default; verify this has not been disabled)

Informal credential storage in ticket fields:

This requires a content audit that cannot be performed through standard navigation. Run a search across recent incident, change, and problem records for patterns indicating credential sharing:

ServiceNow Global Text Search (if enabled): search for terms like password, passwd, secret, api_key, token, credentials in incident and change record descriptions and work notes.

If the search returns results containing actual credential values, initiate a credential rotation programme for any systems referenced and conduct user awareness training on credential handling in ITSM tickets.

Check 5: API Access Log Review

ServiceNow logs all REST API calls in the Transaction Logs. Reviewing these logs establishes a baseline of normal API access patterns and identifies anomalies.

Access REST API transaction logs:

Navigate to: System Logs → Transactions (All) Filter: Type = REST

For the June 2026 incident specifically, filter to the period 2 June to 5 June and look for:

• Requests to /api/now/related_list_edit/create from unexpected IP addresses
• High-volume API requests from a single IP address in a short time window
• Requests from IP addresses that are not known integration sources
• Requests to sensitive table endpoints (sys_user, cmdb_ci) from external IPs

Export the filtered results for incident response documentation.

Assessment Output and Remediation Priority

Consolidate the findings into a risk-prioritised remediation list:

The assessment should be repeated after every major ServiceNow platform update — not as a one-time exercise. Platform updates introduce new endpoints and can change ACL behaviour for affected tables; the security configuration baseline must be re-validated after each upgrade.