Salesforce Experience Cloud Security: Locking down guest users, sharing and public site exposure

A public Salesforce Experience Cloud site runs as a guest user inside your production org, so any object, field or Apex method that guest can reach is readable by anyone on the internet, and automated scanners now look for exactly that. In March 2026 Salesforce Security described a threat actor campaign that mass-scans public Experience Cloud sites with a modified open-source Aura inspection tool and extracts data from orgs whose guest user configuration is too permissive, stating that the issue is not a platform vulnerability. This guide covers the guest user profile and sharing model, Aura and Apex exposure, external user licences and sharing sets, how to test a site, what to log and a hardening baseline. It is written for Salesforce administrators, developers and the security engineers who review customer and partner portals. Org-wide controls such as login policies, connected apps and Shield are in the Salesforce Security Guide.

This is an independent guide from NHI Mgmt Group, based on Salesforce's public documentation as of November 2026. It is not sponsored or reviewed by Salesforce. Product features change, so confirm settings against Salesforce's current documentation.

Key takeaways

• The guest user is a real user with a profile. Everything it can read through object permissions, field-level security and guest user sharing rules is public, so the guest profile deserves the strictest review in the org.
• Guest sharing rules mean unlimited public read. Since Winter '21 guest access to records is Private by default and the only way to open records is a read-only guest user sharing rule, which Salesforce warns gives immediate, unlimited access to every matching record.
• Turn off guest API access. Salesforce calls disabling "Allow guest users to access public APIs" and unticking "API Enabled" on the guest profile the highest-impact single change.
• Apex is the hidden door. An Apex class the guest profile can call, declared without sharing, can return records the sharing model would never expose, so every guest-callable method needs its own access checks.
• Test as an outsider. Browse every public page, search and object link from a private browser window, and use the Guest User Sharing Rule Access Report, remembering that it does not cover every object.

How identity and access work in Experience Cloud

An Experience Cloud site has three kinds of visitor. Guest users are unauthenticated visitors; every site has one guest user record and one guest user profile, and all anonymous traffic runs as that user. Authenticated external users (customers and partners) hold an external licence and a profile, and log in with site credentials, self-registration or single sign-on. Internal users can also be site members. Public access is switched on in Experience Builder with "Guest users can see and interact with the site without logging in", and each page can be set to Site Default, Public or Requires Login; login-related pages are always public.

The guest user model after Winter '21

Salesforce's guest user security documentation describes a series of enforced changes:

These enforcements removed the worst defaults, but they do not stop an administrator from adding a broad guest sharing rule, granting read on a sensitive object, leaving fields visible or exposing an Apex class. Most current exposure comes from those choices.

External users, licences and sharing sets

Authenticated users see records through their licence's sharing features. Sharing sets grant access by matching a lookup on the user (Account, Contact, Contact.RelatedAccount, Manager.Account and similar) to a field on the target record, at Read or Edit, and are available to licences including Customer Community, Customer Community Login, Customer Community Plus and Partner Community. Customer Community Plus and Partner Community licences can also use roles and sharing rules. Two consequences follow: a sharing set mapped on Account gives every contact at that account the same records, and an external role hierarchy can roll partner users' records up to partner managers. Review sharing sets and external sharing rules with the same care as internal ones. See the Least Privilege Techniques Guide.

Admin roles and privileged access

Experience Cloud administration happens in three places: Setup (sharing settings, profiles, permission sets), Experience Workspaces (administration, members, login and registration, preferences) and Experience Builder (site settings, page access, guest user profile link). Control who holds each.

• Customize Application and Manage Sharing: creating sharing sets needs Customize Application and editing them needs Manage Sharing, according to the Metadata API reference. Holders can widen external access; review them as privileged users.
• Site administrators and builders: people who can edit a site in Experience Builder can make pages public and reach the guest profile. Limit site membership with administrative rights to the team that owns the site.
• Developers deploying Apex and components: any deployment that adds an Apex class to the guest profile's class access, or a Lightning component to a public page, is a change to public attack surface and should go through a security review gate.
• Self-registration and account assignment: self-registration creates authenticated users automatically. Salesforce recommends disabling it when not required (Workspaces > Administration > Login & Registration); where it is needed, assign new users to a dedicated account and profile with minimal access.
• Security Contact: Salesforce recommends adding a Security Contact to the org so its security team can reach you during a campaign like the one described in March 2026.

Integrations, API tokens and service accounts

A public site exposes several programmatic surfaces as well as pages. Treat the guest user as an unauthenticated service account and the site's integrations as non-human identities with external reach.

Writing Apex that guests can call

Salesforce's Apex documentation says to declare a sharing mode explicitly on any class that runs SOQL or DML, to use with sharing unless there is a reason not to, and to use without sharing cautiously for targeted elevation, checking that sensitive data is not exposed. From API version 67.0, classes with no declaration run with sharing; in earlier versions, undeclared classes that are not Aura or LWC entry points run without sharing. For guest flows, the Experience Cloud developer guide adds three rules: do not let guests look up records by record ID unless the record should be public, give a guest who creates a record an encrypted identifier instead of the raw ID, and perform any guest update in system context only after verifying that identifier and the record's creator. Sharing alone is not enough for a guest, because guest sharing rules are already public: enforce object and field permissions in the method and return only the fields the page needs. See the Salesforce Apex and Lightning Secure Coding Guide.

Logging and detection

Salesforce's March 2026 guidance recommends reviewing Aura event monitoring logs for signs of scanning. Detection should combine configuration monitoring with request logs.

• Aura request logs: Event Monitoring records Aura requests; look for high request rates from one source against public sites, requests for many object types in sequence and guest sessions returning large record volumes. Field-level detail and retention depend on your Event Monitoring licence; see the Salesforce Event Monitoring Detection Guide.
• Setup Audit Trail: alert on changes to guest user profiles, guest sharing rules, sharing sets, site settings and Apex class access for guest profiles.
• Guest User Sharing Rule Access Report: run it after every release. Salesforce notes that counts above 10,000 are approximate and that some objects, including Contact, Task and Note, are not covered and must be checked manually.
• Self-registration volume: sudden spikes in new external users can indicate automated registration to reach authenticated-only data.

Metrics

• Guest-readable objects: number of objects with read access on guest profiles, with a documented reason for each.
• Guest sharing rules: count of guest user sharing rules and records they expose, reviewed each release.
• Guest API access: sites with public API access or API Enabled on the guest profile, target zero.
• Guest-callable Apex without review: Apex classes enabled for guests without a recorded security review, target zero.
• Time to remediate exposure: hours from a finding in testing or the access report to a fix in production.

Hardening baseline

1. Inventory sites: list every Experience Cloud site, whether it allows public access, its guest profile, its owner and the data it is meant to show. Deactivate sites nobody owns.
2. Audit the guest profile: from Builder > Settings > General > Guest User Profile, remove unneeded object permissions and tighten field-level security on Contact, Lead, Case and custom objects.
3. Set sharing: in Sharing Settings, set external org-wide defaults to Private, confirm Secure guest user record access, and untick Portal User Visibility and Site User Visibility.
4. Disable public APIs: turn off "Allow guest users to access public APIs" and untick "API Enabled" on the guest profile.
5. Review guest sharing rules and Apex: remove guest sharing rules without a business owner, and review each Apex class enabled for guests for explicit sharing and field checks.
6. Protect members and files: disable member visibility for guests, enable Profile Filtering and Show Nicknames, populate the EPIM PII field set, and audit public files and libraries.
7. Test and release: make changes in a full sandbox, test each public page, search, sitemap.xml and direct object links in a private window, then deploy. Keep a record of previous guest profile and sharing settings so a broken public journey can be restored quickly, then fix it with a narrower grant.

Choosing a design

If anonymous visitors only need to submit a form, give the guest create access on one object, assign records to a default owner and grant no read at all. If they need to read published content such as knowledge articles or product data, use a guest sharing rule scoped by a "published" criterion on that object only. If visitors need their own records, require login and use sharing sets rather than guest access. Small teams with one site can usually remove guest read entirely; large organisations running many sites should add a release gate that runs the access report and an outside-in test before any site change ships.

Common misconfigurations

• Guest read on Contact, Case or custom objects: object read left on the guest profile from a past project, with fields visible, giving scanners names, emails and phone numbers that Salesforce says are then used for vishing.
• Broad guest sharing rules: rules whose criteria match far more records than intended, for example every record of a type rather than only published ones.
• Guest API access left on: public API access and API Enabled on the guest profile, which turns the site into an unauthenticated API.
• Without sharing Apex on public pages: a controller written for internal users reused on a public component, returning records by ID with no ownership check.
• Member directories: "Let guest users see other members of this site" enabled without the EPIM PII field set, exposing user details.
• Trusting the access report alone: assuming the Guest User Sharing Rule Access Report is complete, when Salesforce documents objects it does not cover.

Framework mapping

Practitioner checklist

• List every Experience Cloud site with public access and name an owner and an intended data set for each.
• Remove unneeded object permissions and fields from every guest user profile.
• Turn off "Allow guest users to access public APIs" and untick "API Enabled" on guest profiles.
• Set external org-wide defaults to Private and untick Portal User Visibility and Site User Visibility.
• Review each guest user sharing rule and each sharing set against its business purpose.
• Check every Apex class enabled for guests for explicit sharing, field checks and no raw record ID lookups.
• Run the Guest User Sharing Rule Access Report and an incognito test of pages, search, sitemap.xml and object links after every release.
• Alert on guest profile, guest sharing rule and site setting changes in Setup Audit Trail, and review Aura request logs for scanning.

Standards and references

• Salesforce Security: Essential Actions to Secure Experience Cloud Guest User Access
• Salesforce Help: Securing guest user access in Experience Cloud sites (PDF)
• Salesforce Developers: Experience Cloud Developer Guide, guest user guidelines
• Salesforce Developers: Apex sharing keywords
• Salesforce Developers: SharingSet Metadata API reference
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls

Related NHI Mgmt Group resources: Salesforce Security Guide · Salesforce Apex and Lightning Secure Coding Guide · Salesforce Event Monitoring Detection Guide · Salesforce Org Compromise Playbook