In March 2026, Salesforce warned customers that a threat group was mass-scanning public Experience Cloud sites and pulling data out of any site whose guest profile could reach more than it should. The attackers needed no login and no stolen credentials. That made Experience Cloud guest user security an urgent review item for every org with a public site, and the good news is that every fix is a setting you control. The steps below follow the order Salesforce recommends.
Custom Apex on a public site carries the same risk, since @AuraEnabled methods are callable endpoints; the Apex user mode guide explains why. Background on org-wide defaults and sharing sits in the security model deep dive, and if you are moving guest access out of profiles, start with the permission sets migration guide.
What happened
Salesforce Security published its guidance on March 7, 2026, and updated it a few days later as the investigation turned up more exposed configurations. The attackers were running a modified copy of Aura Inspector, an open-source audit tool Mandiant released to help admins find misconfigurations. The original only identifies exposed objects. The modified version goes further and pulls the data out.
Every request went to the site’s /s/sfsites/aura endpoint with no login and no session token. Salesforce was clear that the platform itself wasn’t vulnerable: the exposed sites had guest user profiles that could reach objects and fields nobody meant to publish.
Harvested names and phone numbers are often used for follow-up voice phishing (“vishing”). So the real risk goes beyond a list of leaked contacts: it is the first step of a social engineering attack.
The four access layers for guest users
Salesforce describes guest data access as four layers, checked in order. If any layer denies access, evaluation stops there.
| Layer | What it decides |
|---|---|
| 1. Object access | Which objects the guest can reach at all |
| 2. Record access | Which records within those objects are visible |
| 3. Field-level security | Which fields on those records are visible |
| 4. Field value masking | Whether sensitive values are hidden even when the record is visible |
Most teams know the first three. The fourth is easy to forget, and it matters for User records in particular.
Hardening checklist, in priority order
1. Audit the guest user profile
Open the site’s guest user profile (Setup → All Sites → your site → Builder → Settings → General). For every object permission, ask whether an anonymous visitor genuinely needs it. Start from zero access and add back only what tested site functionality requires.
2. Set external org-wide defaults to Private
In Sharing Settings, set Default External Access to Private for all objects and make sure Secure guest user record access is on. Guests then see no records unless a guest sharing rule grants them.
3. Turn off guest access to public APIs
- In the site settings, uncheck Allow guest users to access public APIs.
- In the guest user profile’s system permissions, uncheck API Enabled.
Salesforce calls this the highest-impact single change. It closes the Aura endpoint to unauthenticated API queries, which is the exact route this campaign used.
4. Restrict user visibility
In Sharing Settings, uncheck Portal User Visibility and Site User Visibility so guests can’t list internal users.
5. Disable self-registration if the site doesn’t need it
Exposed data can be used to register portal accounts, turning guest-level exposure into an authenticated session with more access. If self-registration is required, make sure the registration handler runs with sharing, assigns the most restrictive profile available, and requires email verification.
6. Review Enhanced Personal Information Masking (EPIM)
Standard User fields can’t be restricted with field-level security, so EPIM is the control for them. In User Management Settings, confirm that sensitive fields such as Last Login Date and Last Password Change are in the EPIM protected set.
The fields EPIM protects by default depend on when it was enabled. In orgs that were live before Spring ‘22, Latitude, Longitude, Street, City, State, Postal Code and MobilePhone may not be protected. Check them explicitly.
7. Enable Profile Filtering
Without it, guests may be able to see profile names in your org, including internal ones. With it on, users see only their own profile name unless they hold admin permissions.
8. Enable Show Nicknames
Site members see each other’s real first and last names by default. Turn on Show nicknames in Experience Workspaces (Administration → Preferences). For API access, also enable Hide first and last name fields in the SOAP API for site users in Digital Experiences settings.
9. Review field-level security on every other object
EPIM covers the User object only. For Contact, Lead, Case and any custom object the guest profile can read, go through FLS field by field and remove anything not strictly required. Prioritise Contact email, phone and address fields, Case subject and description, and custom objects holding regulated data. There is no automated check for this step, so it has to be a manual review.
Summary
| Step | Setting | Why it matters |
|---|---|---|
| 1 | Guest profile object permissions | Removes objects guests never needed |
| 2 | External OWD Private and secure guest record access | Guests see nothing without an explicit sharing rule |
| 3 | Public API access and API Enabled off | Closes the Aura endpoint used in the campaign |
| 4 | Portal and Site User Visibility off | Stops enumeration of internal users |
| 5 | Self-registration off | Prevents escalation to an authenticated session |
| 6 | EPIM field set | Protects User fields that FLS can’t restrict |
| 7 | Profile Filtering on | Hides internal profile names |
| 8 | Show Nicknames on | Hides real names between site members |
| 9 | FLS review on other objects | Closes field-level gaps on Contact, Case and custom objects |
Two points worth remembering
A record cap is a performance guardrail. Limits on how many records a component or query returns keep pages fast. They don’t restrict what a guest can reach, because an attacker can change filters, sort orders or pages to walk across the full set. Blocking one bypass just sends them to the next. The only lasting fix is on the guest profile and sharing settings.
Hidden in the UI still means reachable. A public component that doesn’t display a field can still return it in the network response. The Apex user mode guide shows how that happens and how to stop it.
Detection
Review the Aura Event Monitoring logs for:
- Queries against objects that aren’t meant to be public
- Spikes in requests from unfamiliar IP addresses
- Activity outside normal business hours
If you suspect exposure, contact Salesforce Support and complete the audit steps above; low log volume alone doesn’t prove a site is safe. Make sure the org has a designated security contact so Salesforce can reach the right person quickly.
Explaining the incident
Whether you’re briefing a manager or answering an interview question, frame it as a shared-responsibility problem: Salesforce runs the platform, and the customer controls what the guest profile can reach. Then give the top three fixes in order (audit the guest profile, set external org-wide defaults to Private, and turn off public API access) and mention that EPIM covers the User fields FLS can’t.