Experience Cloud security: guest users, sharing and private data

To keep an Experience Cloud site from exposing data, treat it as two audiences with separate controls. Anonymous visitors all run as one guest user per site, and Salesforce now holds that user to private, read-only record access. Logged-in customers and partners reach records through external sharing, roles or sharing sets. Most leaks trace back to settings your team owns: a loose guest profile, a broad sharing rule, public APIs left on, or custom code that ignores sharing.

Who can actually reach your site?

Two groups: anyone on the internet, acting as the site's guest user, and external users who sign in with an Experience Cloud license. Review each one on its own terms.

Every site has a single guest user record and profile that covers all unauthenticated sessions. Whatever that profile can read, any visitor can read, with no named person behind the request. Authenticated external users each get their own user record, license and profile. The license tier decides which sharing tools apply. Basic Customer Community users depend on sharing sets; the Plus and Partner tiers carry roles.

Our portal and PRM guides cover licensing; for security, start with an inventory. List every site in Setup, including pilots and test sites from past projects, with an owner for each. Retire unused sites once nothing live depends on them.

What can a guest user see by default?

Less than in earlier years. Salesforce applies Secure guest user record access to every org with sites, and admins cannot switch it off. Guest org-wide defaults are therefore Private on all objects.

With that setting in force, the only route for opening records to guests is a guest user sharing rule, a criteria-based rule granting read-only access. Manual sharing and Apex managed sharing are not available for guests, and guests cannot be added to public groups or queues. Since Spring '21, Salesforce has also blocked View All, Modify All, edit and delete object permissions for guest users, leaving read and create.

That baseline still leaves room for mistakes. A guest profile can carry read access to objects and fields that no public page renders. A sharing rule with loose criteria publishes every record that matches it, today and in future. Records that guests create, such as form submissions, go to a default internal owner. Confirm that owner is a deliberate choice.

How should external org-wide defaults and sharing sets be set?

Keep every object's external default at Private, and grant access per audience through sharing sets, sharing rules or roles. Do not loosen an internal default just to make a portal page show data.

Salesforce lets each object carry an external default that matches or is stricter than the internal one. Sharing sets give high-volume users access to records tied to their account or contact, such as cases on their employer's account. Check the matching fields on every sharing set, because a wrong lookup can show one customer another account's records.

Two checkboxes in Sharing Settings deserve a look on each review: Portal User Visibility and Site User Visibility. Salesforce advises clearing both unless members genuinely need to find each other. For roles, rules and implicit sharing in general, see our sharing model guide.

Can custom code expose data to guests?

Yes. Apex runs in system context unless written otherwise, so controllers behind site components must enforce sharing, object permissions and field access themselves.

Salesforce's guidance is that any Apex class a guest can reach through a Lightning component should declare with sharing. Sharing alone does not check object permissions or field-level security. The code must enforce those too, for example by running queries in user mode.

Least privilege also decides which classes guests may call at all. The guest profile's Apex class access should list only the classes that public pages use. Ask developers to keep guest-facing methods narrow and return just the fields a page displays. Salesforce warns against retrieving sensitive records for unauthenticated users by guessable values such as record IDs. Flows embedded on public pages need the same scrutiny, especially any set to run in system context.

Should guests have API access?

Almost never. Salesforce’s March 2026 guidance on guest user access put switching off public API access for guests near the top of its list.

Salesforce reported that a threat group was mass-scanning public Experience Cloud sites for guest profiles with excess access. It stated the cause was customer configuration, not a flaw in the platform. Its recommended response was to clear "Allow guest users to access public APIs" in site settings and "API Enabled" on the guest profile. Keep either on only for a documented feature.

Public pages need the same discipline. Experience Builder lets each page be public or require login, so confirm that only pages meant for strangers are public. A list or record component on a public page displays whatever the guest user can read.

How do files and attachments become visible?

Through more routes than most teams expect. Files follow the records or libraries they are shared with, and public links and asset files open for anyone holding the URL.

Salesforce describes content deliveries, the ContentDistribution object behind public links, as giving some control over download and how long a link works. While a link is live, though, anyone who has it can use it. Asset files are built to be public, much like static resources. Files on records follow the visibility of those records, and files in a library shared with a site reach that site's users.

List the public links that already exist, with their creator and expiry, and revoke any nobody can justify. Limit the Create Public Links permission to people who need it. File options vary by template, so confirm current behavior in Salesforce's documentation.

Which site-level security settings matter?

Clickjack protection, the content security policy and trusted script hosts, all found in Experience Builder under Settings, then Security & Privacy.

Clickjack protection decides which pages may frame your site. The default for sites is to allow framing by the same origin only, which Salesforce recommends. Loosen it only for named domains you trust. On Aura sites, Strict CSP blocks requests to other servers, while Relaxed CSP lets you allowlist hosts for scripts. Give every trusted host an owner and a reason. Labels differ between Aura and LWR templates, so check names against current documentation for yours.

How should external users sign in?

With MFA wherever the data warrants it, and with single sign-on when users already hold an identity you trust.

Salesforce's MFA requirement has centered on internal users, so check the current rules for external site users. You can still require it by granting the "Multi-Factor Authentication for User Interface Logins" permission on external profiles. Leave self-registration off unless the site needs it, and send new registrants to a minimal profile. Our single sign-on guide covers identity providers and provisioning.

How do you monitor a site after launch?

Use Login History and the Guest User Sharing Rule Access Report, which come at no extra cost, and add Event Monitoring if you license it. Health Check gives an org-wide baseline rather than a site review.

Login History records attempts to sign in to the org and to Experience Cloud sites, and the Setup page shows the last six months. The Guest User Sharing Rule Access Report shows which objects, records and fields each site's guest user can reach through sharing rules. It flags fields that may hold personal information, and Salesforce lists it for Enterprise, Performance and Unlimited editions. It cannot count results for some objects, including Contact, Task and CaseComment, so review guest rules on those by hand.

Event Monitoring adds detailed activity logs, and its threat detection features include guest user anomaly events. It is sold as part of Shield or as an add-on, so confirm licensing with your Salesforce account team. Health Check scores org settings against the Salesforce Baseline Standard. Finally, add a security contact in the org so Salesforce can reach the right person quickly.

What belongs in a periodic site review?

A short, repeatable checklist, run each quarter and after any release that changes the site.

• Confirm the site inventory: template, status and owner for each one.
• Re-run the Guest User Sharing Rule Access Report and justify each guest rule.
• Compare guest object, field and Apex class access with the current public pages.
• Check that public API access and API Enabled are still off for guests.
• Test as one user from every audience, across two different accounts.
• Review public links, self-registration and MFA coverage for external profiles.
• Scan Login History for bursts of failed external sign-ins.
• Remove trusted script and framing hosts that no longer serve a purpose.

What should you do if you suspect exposure?

Contain first, then investigate. Cut guest access to the affected data, preserve the logs, and bring in Salesforce support and your privacy lead early.

• Remove the permission or sharing rule behind the exposure, or deactivate the site if the scope is unclear.
• Download available logs before they age out, since retention is limited.
• Use Setup Audit Trail to record what changed, when and by whom.
• Open a case with Salesforce and follow your incident plan, including any notification duties.
• Add the gap to the periodic review so the next cycle checks for it.