ServiceNow public widgets and table APIs expose backend records

At a glance

What this is: Bishop Fox’s analysis shows that ServiceNow public widgets and Table REST API endpoints can reveal backend records to unauthenticated sessions when access controls are misconfigured.

Why it matters: IAM, PAM, and platform security teams need to test public ServiceNow surfaces independently because widget controls, table ACLs, and row-level rules can fail differently and expose operational data.

By the numbers:

• 31% had at least one finding.
• Most positive findings came through the ticket-attachments widget (ff26f2b1db12220099f93691f0b8f5ce).

👉 Read Bishop Fox's analysis of ServiceNow public widget and table API exposure

Context

ServiceNow exposure often starts with a governance gap rather than a software defect. Public portals, widget APIs, Table REST API access, and custom ACLs can each make different decisions about the same record, so a locked-down user experience does not prove the backend is protected. For identity and access teams, this is a permissions design problem that sits close to least privilege, authentication boundaries, and auditability.

The identity angle matters because ServiceNow often stores operational records tied to users, requests, assets, and service workflows. Where public sessions can reach those records, the issue is not only data leakage but also misplaced trust in access paths that were never validated from an unauthenticated perspective. That pattern is typical in large, customised enterprise platforms, which makes it a recurring governance issue rather than an edge case.

Key questions

Q: What breaks when ServiceNow public widgets are not tested separately from the Table REST API?

A: Teams can believe an instance is locked down because one surface blocks access while another still returns backend records. Widget ACLs and table ACLs are evaluated differently, so unauthenticated exposure can remain hidden unless both paths are tested from the outside. The practical failure is false assurance, not just missed data.

Q: Why do AI chat tools create risk for identity and access teams?

A: They create risk because users may rely on plausible but unverified output when making identity, access, or security decisions. That can lead to bad approvals, weak guidance, or sensitive data disclosure. The control problem is trust discipline, not just model quality.

Q: How do security teams know if ServiceNow exposure is actually limited?

A: They need evidence from an unauthenticated perspective showing that widgets, table endpoints, and field-level rules all block the same data consistently. A single denied response is not enough. Reliable validation requires checking row retrieval, count-only responses, and any custom widget that can indirectly reach protected records.

Q: Who should own remediation when ServiceNow data is exposed through a public widget?

A: Ownership usually sits with both application security and the platform team, because the fix may involve widget configuration, table ACLs, field rules, and custom logic. If the exposed data includes identity-linked records, IAM governance should also review whether the workflow surface belongs inside the access review scope.

Technical breakdown

ServiceNow widget APIs and public session bootstrap

Service Portal widgets are not just page components. In practice, they behave like data-returning endpoints that can be called at /api/now/sp/widget/{widget_id}. If a widget is configured for public access, an unauthenticated caller may still retrieve ticket metadata, attachment details, knowledge content, or catalog data. The login page can issue a session token that becomes the starting point for further requests, which means the assessment question is whether public session state can reach data that should sit behind stronger authorization, not whether an employee account can read it.

Practical implication: test public widgets from an unauthenticated session, not only from an admin console.

Table REST API exposure and independent ACL evaluation

The Table REST API is a separate access path from widget rendering, and that separation matters. An instance can block one surface while leaving another reachable because table-level, field-level, and row-level ACLs are evaluated independently. That is why checking only the portal view misses exposure that appears directly through /api/now/table/{table_name}. In customised environments, the risk grows because custom roles, tables, and widgets add more places where access rules diverge from operator expectations.

Practical implication: validate the Table REST API separately from portal widgets and compare the two authorization paths.

Count-only leakage versus full row exposure

Not every exposure returns rows. Some misconfigurations reveal only whether matching records exist, creating a count oracle that supports blind inference even when row data is withheld. That distinction matters because count-only access still confirms the presence of sensitive records and can guide further probing. Security teams should treat confirmed counts as evidence of a control failure, but also preserve the difference between metadata leakage and actual data retrieval so remediation can target the exact behavior.

Practical implication: record count-only findings as exposure evidence, but classify them separately from full record access.

Threat narrative

Attacker objective: The attacker wants to enumerate ServiceNow backend records and extract operational intelligence without needing a valid employee account.

1. Entry occurs through a public ServiceNow session that can reach widget or table endpoints without authenticated user approval. Escalation happens when permissive widget or table ACLs allow the session to query backend records. Impact follows when operational data, attachment metadata, or organizational records become visible to an unauthenticated caller.

NHI Mgmt Group analysis

Public portal content is not a proxy for public data exposure. ServiceNow creates a governance trap when teams validate the visible portal but not the backend access path. A widget can appear harmless while still returning record details through the widget API or the Table REST API. That is a least-privilege failure, not a presentation-layer issue, and it demands authenticated and unauthenticated testing as separate control checks. Practitioners should treat portal exposure as an access-control question, not a UI review exercise.

Distinct authorization paths create a false sense of closure. The article shows why a clean result on one ServiceNow interface does not prove the platform is safe. Table ACLs, field ACLs, row ACLs, and widget ACLs can diverge, especially in customised enterprise instances. Access-path divergence: the same record can be denied in one path and disclosed in another, which means governance must evaluate consistency, not just coverage. Practitioners should map every public path to its own control owner and test scope.

Count-only leakage is a real exposure class, not a minor finding. A count oracle confirms that protected records exist and can often support targeted inference or follow-on testing. That matters for identity governance because access decisions often assume that withholding rows is enough. It is not. If the control allows a public caller to prove that sensitive records exist, the boundary has already failed in a meaningful way. Practitioners should classify count-only behavior as a reportable control gap and verify whether it is reachable from anonymous sessions.

Customisation expands the attack surface faster than platform defaults do. Large ServiceNow deployments rarely remain stock, and every custom widget or table becomes another place where access assumptions can drift. That makes ServiceNow exposure a broader governance signal for enterprise workflow platforms, especially where tickets, assets, departments, and knowledge content intersect with identity-linked data. The security team should assume that bespoke portal logic needs the same lifecycle scrutiny as any other access-bearing application component.

For identity programmes, this is a delegated access problem disguised as platform configuration. ServiceNow often contains data tied to human identity, operational roles, and service workflows, so public exposure crosses into IAM governance even when the issue is reported as application misconfiguration. The practical lesson is that access reviews must include externally reachable workflow surfaces, not just user entitlements and privileged accounts. Practitioners should extend identity governance to application endpoints that can disclose identity-adjacent records.

What this signals

Access-path divergence will keep producing silent exposure until teams test public services the way attackers do. ServiceNow is a reminder that workflow platforms need dual validation, not just admin-side review. The real programme signal is that any application with public widgets, APIs, or nested components should be assessed as an access-control surface, and the OWASP Non-Human Identity Top 10 remains useful where those paths touch service accounts, tokens, or backend automation.

Access-path divergence: the next control conversation is about consistency across interfaces, not just whether a system has ACLs. When visible state and backend state disagree, governance breaks down in ways that traditional review processes miss. For practitioners, this means adding unauthenticated validation to application security baselines and tying findings back to NIST SP 800-53 Rev 5 Security and Privacy Controls for access control and audit coverage.

For practitioners

• Test public ServiceNow paths from anonymous sessions Validate both Service Portal widgets and the Table REST API from a session that has no authenticated user privileges, then compare results for row access, count-only leakage, and error states.
• Review custom widgets for unintended data return behavior Inventory custom widgets that expose tickets, attachments, knowledge articles, catalog entries, or list views, then confirm that each one enforces the intended access rule before it returns any backend record.
• Separate row exposure from count-only evidence Classify findings into full record retrieval, confirmed count-only behavior, and blocked access so remediation targets the exact control failure instead of treating all results as the same severity.
• Map each public surface to a control owner Assign ownership for widget ACLs, table ACLs, and field-level rules separately, because a fix in one path does not automatically close the other.

Key takeaways

• ServiceNow exposure here is a control consistency problem, because different access paths can return different answers for the same records.
• The assessment data shows that count-only leakage and full row exposure both matter, since either one can reveal protected operational information.
• Teams should test portal widgets, table APIs, and custom components from an unauthenticated perspective before they assume the platform is properly locked down.

Key terms

• Service Portal widget API: A ServiceNow endpoint that returns widget output to the caller, often including data behind the page rather than just the page chrome. When configured for public access, it can expose records if the widget or its underlying ACLs are too permissive.
• Table REST API: ServiceNow's direct interface for querying table records such as incidents, users, or knowledge articles. It uses its own authorization path, so exposure can exist even when portal widgets appear restricted.
• Count oracle: A response that confirms matching records exist without returning the rows themselves. It is weaker than full data exposure but still reveals sensitive information and can support blind inference or targeted follow-on testing.
• Access-path convergence: A condition where multiple business systems are governed by the same credentials, tokens, or sessions. Once that happens, one compromised identity can provide broad access across cloud, SaaS, email, and operational tooling, which sharply increases ransomware blast radius.

What's in the full report

Bishop Fox's full post covers the operational detail this post intentionally leaves for the source:

• Reproduction-oriented checks for public Service Portal widgets and table endpoints that teams can run in authorised assessments.
• Bounded evidence packaging that separates row exposure from count-only leakage for cleaner remediation decisions.
• The widget candidate list and table-field pairs used to uncover exposure in real ServiceNow environments.
• Practical remediation guidance for custom widgets, ACL review, and indirect access paths.

👉 The full Bishop Fox post covers the snowpick workflow, evidence handling, and remediation guidance.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle discipline. It helps practitioners connect access control failures in enterprise workflows to broader identity governance decisions.