Protecting Your Data: Essential Actions to Secure Experience Cloud Guest User Access

Editor’s note: This post was updated on March 11, 2026 to reflect new findings from our ongoing investigation

Recently, Salesforce Security has been tracking an increase in threat actor activity targeting misconfigurations of publicly accessible sites. Specifically, we have identified a campaign in which malicious actors are exploiting customers’ overly permissive Experience Cloud guest user configurations to potentially access more data than targeted organizations intended.

Since our initial publication, our investigation has identified additional customer configuration scenarios that may result in unintended exposure of customer data. We have updated this guidance with new recommended actions below.

It is important to note that Salesforce remains secure, and this issue is not due to any vulnerability inherent to our platform. Our investigation to date confirms that this activity relates to a customer-configured guest user setting, not a platform security flaw. We are publishing this guidance to help our customers assess and take appropriate action to secure their environment.

About the Threat Actor Activity

Our Cyber Security Operations Center (CSOC) has been monitoring a campaign by a known threat actor group.

Evidence indicates the threat actor is leveraging a modified version of the open-source tool Aura Inspector (originally developed by Mandiant) to perform mass scanning of public-facing Experience Cloud sites. While the original Aura Inspector is limited to identifying vulnerable objects by probing API endpoints that these sites expose (specifically the /s/sfsites/aura endpoint), the actor has developed a custom version of the tool capable of going beyond identification to actually extract data — exploiting overly permissive guest user settings. 

In a publicly accessible Salesforce Experience site, anonymous visitors share a “guest user profile.” Typically this is used to allow an unauthenticated user access to view data that is expected to be made publicly available. However, if this profile is misconfigured with excessive permissions, data that is not intended to be made public may be accessible, allowing a threat actor to directly query Salesforce CRM objects without logging in

For an Experience Cloud customer to be at risk of this threat actor activity:

• They are using the guest user profile
• They have configured the permissions to allow public access to objects and fields not intended to be publicly available, contrary to Salesforce’s recommended configuration guidance.

This threat actor activity reflects a broader trend of “identity-based” targeting. Data harvested in these scans, such as names and phone numbers—is often used to build follow-on targeted social engineering and “vishing” (voice phishing) campaigns.

Understanding Salesforce Experience Cloud Data Access Controls

Salesforce Experience Cloud uses a four-layer security model to control access to data. Each layer is evaluated sequentially  — if access is denied at any layer, the user cannot proceed to the next:

• Layer 1 — Object Access: Determines which objects a user can see at all
• Layer 2 — Record Access: Determines which specific records within those objects are visible
• Layer 3 — Field-Level Security (FLS): Restricts access to specific fields within those records
• Layer 4 — Field Value Masking: Obscures sensitive field values even when a record is otherwise accessible

Access to a field’s value depends on multiple layers of permissions. If any layer is configured too broadly, it can lead to unintended access to data . The recommended actions below are designed to close those gaps.

Recommended Immediate Actions for Customers

Security is a shared responsibility that requires multiple layers of defense. Our detections are designed to complement our customers’ configuration hygiene and proactive security practices. While Salesforce has enhanced its anomaly detection capabilities and continues to invest in advanced measures to help protect our customers in response to a rapidly evolving threat landscape, there are also immediate actions to improve security posture that customers should take – starting with an audit of guest user permissions and enforcing a “Least Privilege” access model an effective defense for your data.

We further recommend: 

1. Audit Guest User Configurations: Review your guest user profile to ensure it is restricted to the absolute minimum objects and fields required for your site to function. 

Implementation steps: Navigate to Setup > All Sites > [Your Site] > Builder > Settings > General > Guest User Profile. For every object permission listed, ask whether an unauthenticated site visitor genuinely requires access to those records. Remove anything that is not clearly required. Start from zero access and restore only what tested functionality requires.

2. Set Org Wide Defaults to “Private”: In Sharing Settings, ensure the Default External Access for all objects is set to Private. 

Implementation steps: In Setup > Sharing Settings, confirm that org-wide defaults for all objects are set to Private for external users and that Secure guest user record access is enabled. Guest users cannot access any record unless you have explicitly created a sharing rule granting access.

3. Disable Public APIs: Uncheck “Allow guest users to access public APIs” in your site settings and uncheck “API Enabled” in the guest user profile’s System Permissions. 

Implementation steps: In your site settings, disable Allow guest users to access public APIs. In the guest user profile’s System Permissions, uncheck API Enabled. This is the highest-impact single change you can make. It closes the Aura endpoint to unauthenticated API queries, which is the exact vector used in this campaign.

4. Restrict Visibility: Uncheck “Portal User Visibility” and “Site User Visibility” in Sharing Settings to prevent guest users from enumerating internal org members. 

Implementation steps: In Sharing Settings, uncheck Portal User Visibility and Site User Visibility to prevent guest users from enumerating internal org members.

5. Disable Self-Registration if Not Required: If your site does not require unauthenticated visitors to create their own accounts, disable self-registration. Data accessible through guest user misconfigurations can be used to self-register portal accounts, escalating a guest-tier exposure into an authenticated session with broader data access.

Implementation steps: Navigate to Setup > All Sites > [Your Site] > Workspaces > Administration > Login & Registration and remove the self-registration page assignment. If self-registration is required for your site to function, ensure the registration handler runs with sharing, assigns the most restrictive profile available, and requires email verification before the account is activated.

6. Review Your Enhanced Personal Information Masking (EPIM) Configuration: When the “Let guest users see other members of this site” setting is enabled, standard User object fields may be visible to guest and external users. Because standard User object fields cannot be restricted using Field-Level Security (FLS), we suggest using Enhanced Personal Information Masking (EPIM) as a security control.

Implementation steps: Navigate to Setup > User Management Settings and confirm that sensitive User fields — such as Last Login Date and Last Password Change — are added to the EPIM PII field set. Note that the fields EPIM protects depend on when it was enabled in your org. For orgs live before Spring ’22, fields including Latitude, Longitude, Street, City, State, Postal Code, and MobilePhone may not be protected by default and should be verified explicitly.

7. Enable Profile Filtering: Without Profile Filtering enabled, guest users could potentially access profiles in your org, including internal profiles. 

Implementation steps: Go to Setup > User Management Settings and enable Profile Filtering. Once enabled, users can only see their own profile name unless they have explicit administrative permissions.

8. Enable Show Nicknames: Real first and last names are visible to other site members by default. Enabling “Show Nicknames” masks users’ real names for other site members.

Implementation steps: In Experience Workspaces, go to Administration > Preferences and enable Show nicknames. For additional protection via API, also enable “Hide first and last name fields in the SOAP API for site users” under Setup > Digital Experiences > Settings.

9. Review Field-Level Security for Non-User Objects: EPIM only protects the User object. For all other objects where sensitive data exists — such as Contact, Lead, Case, or custom objects — Field-Level Security (FLS) is the appropriate control for guest and external users.Implementation steps: For every object the guest user profile has Read access to, review FLS field by field and remove access to any field not strictly required. Prioritize Contact (Email, Phone, Address fields), Case (Description, Subject), and any custom objects storing regulated or sensitive data. There is no automated check for this — it requires a manual review.

Ongoing Investigation and Monitoring:

• Review Event Monitoring Logs:
  • In addition to checking for unusual query volumes, review your Aura Event Monitoring logs for anomalous access patterns — such as queries targeting objects not intended to be public, unexpected spikes from unfamiliar IP addresses, or access outside normal business hours.  If you suspect your environment may have been affected, contact Salesforce Support and complete the guest user audit steps outlined above rather than relying on log volume alone.
• Add a Security Contact: Ensure your org has a designated Security Contact so our team can reach the right person immediately if suspicious activity is detected.

Salesforce’s Commitment to Trust

If Salesforce becomes aware of unauthorized access to customer data, we notify impacted customers without undue delay. Our teams work around the clock to share information with the threat intelligence community to help ensure our customer’s security. Public Security Advisories are available on our Trust site.

While our platform remains resilient, maintaining a secure environment is a shared responsibility that requires consistent, coordinated action. For more resources and the latest step-by-step guides, visit our Security Best Practices.

Additional Resources

For more detailed guidance on securing Experience Cloud guest user access, review the resources below to help assess your configurations and implement recommended safeguards. 

• How to Prevent 3 Common Misconfiguration Mistakes
• Control Public Access to Your Site with the Guest User Profile
• Securely Share Your Experience Cloud Sites with Guest Users
• How the guest user profile controls access to data in publicly accessible sites
• Guest User Record Access Development Best Practices
• Salesforce Security Best Practices