Salesforce Experience Cloud: The Multi-Million Dollar Misconfiguration Problem

# Salesforce Experience Cloud: the multi-million dollar misconfiguration problem

Every Experience Cloud audit I've run in the last 18 months has produced at least one guest-user-exposes-customer-data finding. Not "maybe." Not "sometimes." Every single one.

Varonis published the research in 2022. Salesforce shipped guidance. The press cycle moved on. And the misconfiguration is still everywhere. If your company runs Experience Cloud, Community Cloud, or any of the legacy Customer/Partner Community features, anonymous internet users are probably reading your Salesforce data right now and you don't know.

The reason it persists is subtle. Salesforce ships Experience Cloud with permissive defaults because restrictive defaults break more customer rollouts than they prevent breaches. The responsibility moves to the admin. The admin doesn't know the restriction exists. The guest profile ends up with View All on too many objects. Attackers who know the enumeration endpoints pull everything.

#What's the misconfiguration

Here's the part consultants don't put in the glossy PDF.

Salesforce Experience Cloud lets you stand up a customer-facing portal that reads and writes to your Salesforce data. Customers log in, submit support cases, view account information, update profiles, etc. It's powerful and widely deployed. Tens of thousands of public-facing Salesforce Experience Cloud sites exist.

The issue: Experience Cloud portals have a concept of a "guest user". An unauthenticated visitor. Guest users are assigned a default profile. The default profile can have object-level access to Salesforce objects (Accounts, Contacts, Cases, custom objects, everything).

In a misconfigured deployment, the guest user profile has read access to objects that contain sensitive customer data, employee data, or internal records. An anonymous internet visitor can query those objects through the Experience Cloud Aura / Lightning Web Component APIs and retrieve data they should never see.

The attack doesn't require authentication. It doesn't require a user account. Anyone on the internet who knows (or guesses) the portal URL can retrieve data.

#How to exploit

The attack pattern is well-documented and has been used in multiple breaches:

1. Visit the public Experience Cloud site
2. Open browser developer tools
3. Inspect the Aura network traffic (or use a tool like the Aura Enumeration tool from Varonis)
4. Identify the Aura.ActionControllers endpoint (typically /s/sfsites/aura)
5. Craft Aura action requests to RecordUiController or similar controllers that accept recordId parameters
6. Enumerate record IDs, extract data from each

Salesforce record IDs are predictable. The first 3 characters identify the object type ("001" for Account, "003" for Contact, "500" for Case). Subsequent characters are a sequential counter. Once one valid ID is found, others can be enumerated by varying the last few characters.

Tools like Nuclei, Burp extensions for Aura testing, and custom scripts automate this. The Salesforce guest user apparent in the response either has read access and returns data, or lacks read access and returns a permission error. Either way the attacker learns what's exposed.

#Who has been affected

Public cases:

• Vermont Health Access. 2023 breach traced to Experience Cloud guest user misconfiguration
• Several US state government portals (2022-2024 period). Experience Cloud misconfigurations exposed personally identifying information
• Multiple banks and insurance companies that declined to be named. Disclosed in aggregate metrics
• Recently (Q4 2025 - Q1 2026). Several healthcare providers with misconfigured patient portals

The pattern is consistent: organization stands up Experience Cloud for a specific customer-facing use case. Administrators configure the portal functionally but don't hand the permissions to a security engineer for review. The guest user profile defaults aren't tightened. Data is exposed for the lifetime of the portal until someone audits it.

#How to audit your own

If you run Salesforce and have any Experience Cloud site, perform this audit:

#1. Identify all Experience Cloud sites

Salesforce Setup > Digital Experiences > All Sites. List every site.

#2. For each site, inspect the guest user profile

Each site has a guest user. Find it: Site > Administration > Guest User Profile.

#3. Audit object permissions on the guest user profile

The guest user profile should have:

• Read access to ONLY objects that are intentionally exposed to anonymous visitors (typically none, or only specific public-facing FAQ-style objects)
• NO read access to Accounts, Contacts, Cases, User, custom objects with sensitive data
• NO edit / create / delete on anything unless explicitly needed

Use the Field-Level Security tab to verify field-level permissions match.

#4. Audit sharing rules

Even with tight profile permissions, sharing rules can grant guest user access to specific records. Setup > Security > Sharing Settings. Check for any rule that includes the guest user or the "All Internal Users" group (guest user is sometimes inadvertently included).

#5. Audit Apex class access

The guest user may have access to Apex classes that return data. Profile > Apex Class Access. Only allow Apex classes that have been specifically audited to operate safely in unauthenticated context.

#6. Test the portal as an anonymous visitor

Open the portal URL in an incognito window. Use browser dev tools to inspect what network traffic fires. Check if any of the returned data includes sensitive fields. Check if the page source includes any recordIds that could be enumerated.

#7. Run Salesforce Health Check

Salesforce's own Health Check scoring will flag some Experience Cloud issues, but not all. Use it as a starting point, not a complete audit.

#8. Use Varonis's free Salesforce scanner or commercial tools

Varonis DatAdvantage Cloud, AppOmni, Adaptive Shield, Obsidian. All offer Salesforce security configuration audits that include Experience Cloud guest user checks. Worth running.

#Salesforce's 2023-2026 mitigation efforts

To their credit, Salesforce has shipped improvements:

• Guest User Access Report. Built-in tool (Setup > Session Settings) that enumerates guest user permissions.
• "Secure guest user record access" critical update. Disabled implicit guest user sharing for newly-created objects. Must be explicitly enabled on newer orgs.
• Salesforce Security Center. Enterprise feature that centralizes security posture across multiple orgs, including Experience Cloud issues.
• Default settings changes. Newer Experience Cloud sites default to tighter guest user permissions than the originals.

But: organizations that stood up Experience Cloud sites before these improvements retain the old defaults unless they migrate or reconfigure. That's most deployments.

#What a pentest engagement does

Our Salesforce security engagements include:

1. Inventory of all orgs, sandboxes, and Experience Cloud sites
2. Guest user profile audit across all sites
3. Sharing rule review for inadvertent guest user inclusion
4. Apex class and Lightning Web Component access review
5. Integration user audit (often over-permissioned. See below)
6. Multi-tenant isolation testing for multi-brand deployments
7. OAuth connected app review (stolen refresh tokens are a separate problem)
8. Field-level security configuration review
9. Production exploitation attempt from anonymous perspective
10. Report with specific remediation steps and Salesforce-recommended configuration

The common findings beyond guest user issues:

• Integration users with "System Administrator" profile. A compromised integration user is full org compromise.
• OAuth connected apps with broad refresh token scopes and no IP restrictions.
• API users with no session timeout.
• Unmanaged packages from the AppExchange with their own security debt.
• Mobile app configurations exposing data through the Salesforce Mobile App to users who shouldn't have it.

#Broader SaaS security lessons

Salesforce is one specific platform but the pattern generalizes:

• Workday, ServiceNow, Microsoft 365, Google Workspace, Slack. Every enterprise SaaS platform has guest user / external sharing / public link misconfigurations
• The security model of each platform is different and non-obvious
• Default configurations tend to prioritize functionality over security
• No single "SaaS security scanner" covers all platforms well
• Periodic platform-specific security reviews are necessary

For PCI DSS, HIPAA, or SOC 2 organizations: your SaaS platforms are in scope for compliance even if they're not operated by you. Your auditor expects evidence of configuration review.

#Resources

• Salesforce Guest User Security Best Practices: https://help.salesforce.com/
• Varonis research on Salesforce Community Cloud issues (2022 original research)
• Salesforce "Secure Guest User Record Access" critical update documentation
• AppOmni, Adaptive Shield, Obsidian Security. Commercial SaaS security platforms
• Salesforce Security Center (enterprise only)

#Hire Valtik Studios

If your organization runs Salesforce in production with any public-facing Experience Cloud site, we run engagement-grade audits that find the guest user misconfigurations before they appear in a breach disclosure. The audit takes 1-2 weeks, produces findings mapped to your org's specific configuration, and includes remediation guidance.

Reach us at valtikstudios.com.