ServiceNow public widgets and table APIs expose backend records

At a glance

What this is: This is an analysis of ServiceNow exposure through public widgets and table APIs, with Bishop Fox showing that unauthenticated paths can return backend records or count-only evidence.

Why it matters: It matters because IAM and platform teams cannot treat portal visibility as proof of access control, especially when public widgets and API surfaces are evaluated separately.

By the numbers:

• 31% had at least one finding.
• roughly 15 organizations, or about 75% of the organizations in the dataset, were affected.

Context

ServiceNow exposure is a governance problem before it is a tooling problem. Public portal components can look harmless while still acting as data retrieval surfaces, especially when widget logic, table access, and ACLs are evaluated independently. That makes unauthenticated validation essential, not optional, for environments that use ServiceNow as an operational system of record.

The identity angle is indirect but real: ServiceNow often stores records tied to users, tickets, assets, and internal operations, so access mistakes become data exposure mistakes quickly. Where portals, widgets, and APIs are public-facing, security teams need to verify what an anonymous session can actually reach rather than assuming the admin console reflects real exposure.

Key questions

Q: What breaks when a public ServiceNow widget is treated as harmless UI?

A: The assumption breaks when the widget returns backend records through its own API path. A public widget can expose ticket metadata, knowledge base content, catalog data, or attachment details even when the page itself looks locked down. Teams need to test widgets as data endpoints, not just as portal components, because the presentation layer and the authorization layer can diverge.

Q: Why do separate ServiceNow widget and table checks matter?

A: They matter because each surface evaluates access control independently. A portal can block one path and still allow the other, which means a clean widget result does not prove table data is safe, and a safe table result does not prove widgets are safe. Independent checks are the only reliable way to confirm what an unauthenticated user can actually reach.

Q: Where does ServiceNow exposure fail in practice?

A: It fails when teams rely on layered ACLs and assume the layering itself guarantees safety. Table-level, field-level, row-level, and widget-level controls can drift apart, especially in customised environments. That drift creates the false confidence that the front end is secure while the backend path still returns data or confirms record existence.

Q: How should organisations respond when a ServiceNow surface returns count-only evidence?

A: Treat it as a security finding, not as a benign partial result. Count-only responses confirm record existence and can support inference, reconnaissance, or targeted probing even when rows are withheld. Teams should document the result, review the underlying ACL path, and verify whether filters or alternate endpoints turn the count signal into broader disclosure.

Technical breakdown

Why public ServiceNow widgets behave like data APIs

Service Portal widgets are not just page components when exposure testing is concerned. They can return records through /api/now/sp/widget/{widget_id}, and if a widget is public or its backing ACLs are too loose, an unauthenticated caller can retrieve ticket metadata, knowledge base content, catalog data, or attachment details. The key technical point is that the widget layer has its own authorization logic, so a locked-down front end does not guarantee the underlying data path is blocked. In ServiceNow, presentation and authorization can diverge.

Practical implication: Test public widgets as data-returning endpoints, not only as user interface elements.

Why the Table REST API can expose data that widgets miss

The Table REST API is a separate access path with its own ACL evaluation chain. That means a ServiceNow instance can look safe through portal widgets while still returning rows through /api/now/table/{table_name}, or the reverse. This matters because table-level, field-level, and row-level rules may be configured inconsistently across custom tables and standard tables. The exposure surface grows in mature environments where customisation is common, because each additional table or role mapping can create a new mismatch between intended and actual access.

Practical implication: Validate widget access and Table REST API access independently from an unauthenticated perspective.

How count-only responses create blind inference risk

A count oracle is weaker than direct row exposure, but it still confirms that records exist. When a platform returns counts without rows, testers or attackers can sometimes vary filters and infer more than the interface intended to reveal. That is why separating count-only behavior from true row retrieval is important. The difference matters operationally because teams often treat visible data and record existence as the same risk, when in practice count leakage can still support reconnaissance, targeting, and follow-on probing against sensitive tables.

Practical implication: Treat count-only responses as findings and test whether they can be chained into broader inference.

Threat narrative

Attacker objective: The objective is to obtain backend ServiceNow records or confirm their existence from an anonymous session, then use that exposure to map internal operations and target higher-value data.

1. Entry occurs through an unauthenticated public session that can reach portal widgets or table endpoints without a trusted user account.
2. Credential or access misuse follows when the exposed widget or table path returns backend records through permissive ACL evaluation.
3. Impact is backend record disclosure, often limited to operational metadata at first but potentially extending to users, credentials, or other sensitive tables if the same pattern is reused elsewhere.

Breaches seen in the wild

• Firebase misconfiguration exposure 2024: Missing Firebase security rules on 916 websites exposed 125 million user records and 19.87 million plaintext passwords; a quarter were fixed.
• Microsoft SAS token exposure 2023: An over-permissive Azure SAS token in a Microsoft AI GitHub repo exposed 38TB, including workstation backups and Teams messages, for 3 years.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

ServiceNow public exposure is an access-control mismatch problem, not a portal problem. The visible interface can look closed while the widget or table path remains reachable through a different authorization check. That gap is especially dangerous in platforms that store operational data, because the security boundary is often assumed to be the portal page rather than the API behind it. Practitioners should treat every public ServiceNow surface as a separate trust decision.

Count-only leakage is a real governance failure, even when no rows are returned. A count oracle does not reveal the full record set, but it still confirms that records exist and can support follow-on inference. That makes the failure mode broader than simple disclosure. The governance assumption that “no rows means no exposure” breaks down as soon as the platform returns metadata about existence or volume. Practitioners should classify count responses as exposure signals, not harmless noise.

Custom widgets create exposure debt. Each in-house widget or table mapping introduces a new place where public access may be granted unintentionally, and the risk increases when teams rely on inherited assumptions from standard widgets. ServiceNow surface sprawl is the right named concept here: multiple public entry points, each with its own ACL path, create security debt that admin reviews often miss. Practitioners should inventory and test custom widgets as part of the same control set as table access.

Identity-adjacent records become sensitive once access control is inconsistent. ServiceNow often holds user-related, operational, and asset data in the same platform, so weak authorization can turn routine records into reconnaissance material. That does not make this an IAM problem in the narrow sense, but it does make access governance central to the outcome. Security teams should align portal exposure testing with broader data classification and authorization review.

Unauthenticated validation is the only meaningful test for public exposure. If a control is only checked from an admin context, the result can be misleading because the public session follows a different path. The article shows why independent validation matters: the same instance can appear safe in one surface and exposed in another. Practitioners should prove access state from the perspective that matters, not from the perspective that is easiest to inspect.

From our research library:

• 73% of vaults are misconfigured, leading to unauthorised access and exposure of sensitive data, according to the Ultimate Guide to NHIs.
• Read next: Guide to the Secret Sprawl Challenge

What this signals

ServiceNow surface sprawl: multiple public entry points, each with its own ACL path, create exposure debt that admin reviews often miss. That means teams need to test portal widgets, table APIs, and custom widgets as separate trust boundaries, not as one blended control surface.

The operational lesson is straightforward. If an unauthenticated session can confirm record existence or retrieve backend rows, the issue is already beyond a simple portal configuration error and should be treated as an access-control gap with data exposure potential. According to the Ultimate Guide to NHIs, 73% of vaults are misconfigured, leading to unauthorised access and exposure of sensitive data, which is a useful reminder that misconfiguration often hides behind apparently functional controls.

For practitioners

• Audit public Service Portal widgets Review every widget reachable through unauthenticated or lightly authenticated paths, especially widgets returning ticket, attachment, knowledge base, catalog, or list data.
• Test the Table REST API separately Run independent unauthenticated checks against /api/now/table/{table_name} because a clean widget result does not prove table access is blocked.
• Classify count-only responses as findings Record count oracles alongside full row exposure so teams can see where existence leakage may support inference or follow-on probing.
• Review custom widgets before release Validate in-house widgets and custom tables for anonymous access paths, since local assumptions about intended visibility are the most common source of drift.
• Reproduce exposure from a public session Use the same unauthenticated perspective a real outsider would have, rather than relying on administrator views that bypass the exposure condition.

Key takeaways

• ServiceNow exposure often comes from mismatched authorization paths, not from a visible portal failure.
• Count-only responses still matter because they confirm record existence and can support inference.
• The practical fix is independent unauthenticated testing of widgets, tables, and custom surfaces.

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 Control List: A list attached to a resource or network object that specifies who can access it and what they can do. ACLs are precise, but at scale they can fragment visibility and make central review harder for security teams.

Deepen your knowledge

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