According to Reco's writeup, the common thread across every technique is the same underlying issue: a guest identity that was granted more access than the site actually needed to serve the public. Salesforce Experience Cloud sites and ServiceNow portals both maintain a persistent guest user that unauthenticated visitors execute as, and that user cannot be deleted, only restricted. If the guest profile can read a record, the record is effectively public, whether or not the site requires login to view it in a browser.
[…]
Remediation, per the research, centers on tightening the guest profile rather than the endpoints themselves, since both the UI-API and the ServiceNow search endpoint are working as designed. On Salesforce, that means reviewing guest sharing rules, stripping unnecessary object and field level access from the guest profile, disabling self registration where it is not required, and turning off the Experience Builder setting that allows guest users to reach public APIs. On ServiceNow, the fix is mapping which search sources are exposed to public facing portals and auditing the Knowledge Base read criteria that decide what an anonymous search actually returns.
I wonder how many other services have the same problem? This sounds like something that could be common in the ERP/CRM/related spaces if they include a customer portal.