ServiceNow REST and SOAP Integrations: Security and Access Design

REST and SOAP integration security means choosing an authentication method the external system supports, giving each integration its own least-privilege service account, and protecting data in transit and at rest. Credentials belong in a secrets manager, and sensitive request data should not be logged.

Authentication and Authorization

External systems accessing ServiceNow must authenticate. REST API uses authentication tokens or OAuth. SOAP uses WS-Security standards. Choose the authentication mechanism that the external system supports and that your security policy requires.

API authentication is different from user authentication. A user has an identity and password. An API client (an external system) has a service account and credentials. Service account credentials should be secrets managed securely, not hardcoded in applications. Use your secrets management tool to store and rotate credentials.

Authorization determines what an authenticated client can do. A service account should have the minimum permissions required for its integration. If a billing system integration only needs to read customer data and create invoice records, give it permissions to read customer table and create on invoice table. Do not give it delete permissions or access to other sensitive data.

Least Privilege for API Accounts

Every service account should have a specific purpose and narrow permissions. Create a service account “billing system integration” with permissions only for that integration. Do not create a generic “integration account” with permissions for everything. When security is breached or an integration compromises, the blast radius is limited.

Audit service account permissions regularly. If a service account has been inactive for six months, delete it. If an integration no longer needs certain permissions, remove them. Do not accumulate permissions that are no longer used.

Document the purpose of each service account and why it needs each permission. This documentation helps future audits and helps you understand what can be safely removed when integrations change.

Data Encryption and Protection

Data in transit must be encrypted. REST and SOAP should always use HTTPS/TLS, never unencrypted HTTP. This protects data from being intercepted in transit. Verify that your integration clients are configured to use HTTPS and that certificate validation is enabled.

Data at rest is also important. Credentials should be encrypted in your secrets manager. Audit logs should be stored. Request and response data can be logged for troubleshooting but should be treated as sensitive. Do not log full request bodies that contain passwords or sensitive customer data.

Implement rate limiting to prevent abuse. An attacker that discovers an API endpoint should not be able to make unlimited requests. Rate limiting protects the service from denial of service attacks. Most REST implementations allow rate limiting per client, per token or per IP.

Segregation of Duties

Some operations should never be performed by the same account. A billing integration should not be able to modify user accounts. An HR integration should not be able to access financial data. Design permissions so that no single compromised account can cause major damage.

Different integrations should have different service accounts. Do not share one account across multiple integrations. If one integration is compromised, only that integration’s data is at risk.

Users should not have the same permissions as integrations. Give users only the permissions they need for their job. Give integrations only the permissions they need for their specific purpose.

Audit and Compliance

Enable audit logging for all API requests. Log includes: what was requested, when, which account made the request, what data was returned. This audit trail is essential for compliance and for detecting suspicious activity.

Review audit logs regularly. If an integration makes unexpected requests or accesses data it should not, the logs will show it. Quarterly reviews of audit logs identify anomalies (sudden spike in API calls, requests outside business hours, access to unexpected tables).

Retain logs for the period required by applicable regulations and policy. Regulatory requirements can mandate audit log retention. Even without regulation, historical logs are valuable for incident investigation.

Integration Architecture Considerations

Decide whether external systems call ServiceNow APIs (pull pattern) or ServiceNow calls external systems (push pattern). Pull is simpler to secure (ServiceNow API endpoints are well-protected). Push requires outbound connectivity and secrets management in ServiceNow (which is generally secure but adds complexity).

Use API keys for less critical integrations. Use OAuth for integrations that need fine-grained permissions or that require long-term access. Document your choice and the reasoning.

Consider API versioning. When you make breaking changes to an API, old clients should continue working with an older API version. This prevents integrations from breaking unexpectedly and gives clients time to upgrade.

Common Security Mistakes

Hardcoding credentials in code is a critical mistake. Credentials in code are visible to anyone with access to the code repository. They are often committed to version control history forever. Use secrets management always.

Using overly broad service account permissions is a common mistake. An account with global admin privileges defeats the purpose of access control. If you find yourself giving a service account many permissions, redesign the integration to require fewer permissions.

Disabling certificate validation to work around SSL errors is a dangerous practice. Certificate errors indicate a security issue. Fix the root cause (update certificates, fix hostname mismatches) rather than disabling validation.

RACI for Integration Security

Design the access at the level where the platform enforces it

Access design for integrations is often written as a principle and then implemented as one broad role. The platform enforces access at the table, field and operation level, and that is where the design has to be made. For each connection, list the tables it reads, the tables it writes, and the fields involved in each. Then check that the identity’s access reaches those fields and nothing else. A connection that needs to read one status field from a table should not be able to read the description field beside it, even if the business does not consider the description sensitive today.

Choose what to expose through each interface

Map inbound endpoints to roles and access controls

A scripted REST resource gives the outside caller a route into the platform, and that route needs its own access rules. Attach the resource to a role that exists only for that purpose, and write access control rules that match the table and field access the resource actually performs. Review the resource’s script for any operation that bypasses those rules, because a script that runs with elevated rights can make a narrow role irrelevant. A resource that accepts writes should also check that the caller is allowed to write the specific record it names, not only the table.

An ordered rotation sequence for a shared credential

Credentials that many flows share are often the hardest to rotate, because a change breaks every consumer at once. The sequence below avoids that outcome when it is followed in order.

1. List every flow, outbound message and endpoint that references the credential, using the register rather than memory.
2. Create the replacement credential with the same access and test it against a sub-production copy.
3. Point one low-risk flow at the replacement and confirm its successful calls in the logs.
4. Move the remaining flows in groups, checking each group’s logs before moving the next.
5. Disable the old credential only after no call has used it for the agreed observation period.
6. Log the rotation and who approved each step.

What to do after a suspected exposure

When a credential may have leaked, the first actions are containment, not investigation. Disable the credential or revoke the token, then identify the calls made with it since the suspected exposure using the platform’s request records. Only then rotate the replacement and restore the affected flows. Teams that begin by tracing the source of the leak often leave the credential active while they search. Keep the containment steps in the runbook so that the responder does not have to decide them under pressure.

An access review that finds real problems

A quarterly access review is more useful when it compares each identity’s current access with the purpose recorded in the register. Look for identities whose connection no longer exists, identities with fields outside their stated purpose, and identities that were last used long before any active flow. Remove access that no flow requires, and record the removal so the next review does not reopen the question. A review that only confirms that the identities still exist will miss the broadened access that matters most.

Questions about securing integration access

Is it enough to restrict the table, or do we need field-level rules?

For connections that carry personal or financial fields, field-level rules are needed, because table access alone exposes every column. For operational data with no sensitive fields, table-level control with an explicit field list in each query is usually proportionate.

Should inbound callers use the same identity as outbound flows?

No. Inbound and outbound identities should be separate, so that a leak in one direction cannot be used in the other and so that audit records show which direction an action came from.

How do we protect a scripted endpoint that other teams call?

Give it a dedicated role, document the fields it returns, and require a consumer agreement before a field is added or removed. The endpoint becomes a contract, and its access control is part of that contract.

Ask for an access review against real identities

An access design is easiest to check against the actual identities and fields on your instance. The best practices guide covers the authentication choices for these connections, and the roles and RACI guide covers ownership. The explainer on access control lists describes the rules that enforce the design, and the article on discovery credential governance covers how access and scope are governed for discovery credentials.