Notifications
Clear all
Topic starter
11/08/2026 3:17 pm
TL;DR: ServiceNow portals can expose backend records through public widgets and table APIs even when the front end looks locked down, and Bishop Fox’s snowpick tested 166 authorized assessments to separate real row exposure from count-only leaks. The core problem is that layered ACLs create false confidence when widget and table authorization paths are not validated independently.
NHIMG editorial — based on content published by Bishop Fox: ServiceNow public widgets can expose backend records through unauthorised API paths
By the numbers:
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
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.
👉 Read Bishop Fox's analysis of ServiceNow public widget and table API exposure →
ServiceNow public widgets and table APIs: where exposure still happens?
Explore further
11/08/2026 3:30 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: ServiceNow public widgets and table APIs expose backend records
