Experience Cloud Guest Access Audit: What Anonymous Visitors Can Reach (and How to Check Before Spring '27)
A guest-access audit checks four layers: objects the guest user can read, records that sharing rules expose, fields that FLS allows, and values that are masked. Winter '27 adds warning icons; Spring '27 enforces a new masking field set. Here's how to audit before the enforcement.
Short answer: A guest-access audit checks four layers, in order: 1. Objects the guest user profile can read 2. Records that guest sharing rules expose 3. Fields that field-level security allows 4. Values that are masked
Winter '27 adds warning icons in the Guest User Sharing Rule Access Report next to fields that may expose personal information. In Spring '27, Salesforce plans to enforce a release update that gives guests their own masking field set (`Guest_PersonalInfo_EPIM`). Treat the icons as a place to start, not a verdict, and test from an anonymous browser, not just from Setup.
Why guest access is back on the list
In March 2026, Salesforce Security warned that attackers were mass-scanning public Experience Cloud sites, probing `/s/sfsites/aura` with a modified Aura Inspector tool and pulling data through overly permissive guest settings. Salesforce said this was "not due to any vulnerability inherent to our platform." The cause was guest-user settings configured by customers.
What's new
- **Winter '27:** warning icons in the Guest User Sharing Rule Access Report. A flagged field isn't a breach, and an unflagged field isn't proven safe.
- **Spring '27 (planned):** the "Conceal Personal Information Fields from Guest Users" release update. It adds `Guest_PersonalInfo_EPIM` for unauthenticated guests, while `PersonalInfo_EPIM` continues to govern logged-in portal users. Check Trust and Release Updates for your instance's timing.
What the report won't tell you
It covers access through guest sharing rules only. It doesn't cover profiles, field-level security, Apex, flows, APIs or self-registration. Reported limits: counts above 10,000 are approximate, and some objects are omitted, including EmailMessage, Contact, CaseComment, Task, Note and AccountContactRelation. A missing number doesn't mean zero exposure.
The audit, layer by layer
*1. Inventory every public site and journey.** Include Aura, LWR, Visualforce and Salesforce Sites. For each, record the owner, whether anonymous access and self-registration are really needed, and which objects and fields each page, form or search reads or creates. Start from the smallest legitimate public service. *Done = one row per site.
*2. Object access.** Strip the guest profile to the minimum, and check any permission sets assigned to the guest user. *Done = only tested journeys have access.
3. Record access. Set Default External Access to Private and turn Secure guest user record access on. Give every guest sharing rule an owner, a justification and narrow criteria. Run the report for every site, and review the omitted objects separately.
4. Field access. Check field-level security field by field, starting with Contact, Case and custom objects. Page layout isn't a security boundary (see our [field-level security fix](https://www.wrenk.ai/fix/field-level-security)). Trace fields returned by `@AuraEnabled` Apex, `without sharing` classes, dynamic SOQL, flows, files and error messages.
5. Value masking. Set up enhanced personal information masking on User fields. Turn on Show Nicknames. Turn off Portal/Site User Visibility.
6. Public APIs. Turn off "Allow guest users to access public APIs" and uncheck "API Enabled" on the guest profile unless a journey truly needs them. Salesforce calls this the highest-impact single change.
7. Self-registration. Keep it off unless it's required. If it is, use a restrictive handler.
Prepare for Spring '27 guest field masking
List the Apex, flows and components that read User fields. Masked fields can come back blank, for example relationship fields or profile photo and banner URLs. Activate the update in a representative sandbox, and test guest and logged-in portal journeys separately. Keep evidence.
Test from outside
In an anonymous browser, check that: - Only the intended fields are visible - Changing an ID, filter or search term doesn't reveal neighboring records - Create-only forms don't echo back records - Files, errors, autocomplete and related lists are clean - Logged-in portal users still work
Keep it from drifting
Give every site an owner. Repeat the audit after each release and each site change. Review Aura event monitoring where you're licensed for it. Set a security contact, and decide who can deactivate a site during an incident.
Checklist
| Site | Type | Owner | Anonymous needed? | Self-reg? | Guest objects (R/C) | Guest sharing rules + justification | Omitted objects reviewed? | FLS reviewed? | Apex/flows exposed | Public API off? | Guest masking configured? | Anonymous test passed? | Next review | |---|---|---|---|---|---|---|---|---|---|---|---|---|---|
FAQ
What can a guest user see?
Whatever the four layers allow: object permissions on the guest profile, records exposed by guest sharing rules, fields allowed by field-level security, and values not masked.
Is the access report a complete audit?
No. It covers guest sharing rules only. It doesn't show profile permissions, field-level security, Apex, flows, APIs or self-registration. Some objects are omitted, and counts above 10,000 are approximate.
Should guest users have API access?
No, unless a documented journey needs it. Turning off guest API access is Salesforce's highest-impact single recommendation.
Was the 2026 exposure a Salesforce vulnerability?
Salesforce says no. It came from customer configuration.
How often should we re-audit?
After every release and every site change.
Want a quick read on your org's overall health? Answer three questions in the free health check. It needs no account and no sales call: [Start the free health check →](https://wrenk.ai/free-health-check?utm_source=wrenk_insights&utm_medium=blog&utm_campaign=wrenk-13-guest-access)