Experience Cloud Security

Experience Cloud User Types

Security in Experience Cloud starts with knowing who your users are. There are two perspectives on this, firstly the use-case and secondly the technical aspects of their representation.

For the use-case, we want to think about who is this person and what is their relationship to your business. From a security perspective we are thinking about risk, control and 'blast radius'.

For the technical side we need to understand how salesforce represents these users in its implementation and the impact that has on the security controls we have. Users in salesforce are well known to the average salesforce implementer, however, when we get to Experience Cloud Sites there are specific technical traits which may not be obvious even to a well-seasoned salesforce specialist.

In the final part of this article I will discuss the Guest User, not because it is overlooked, it increasingly isn't, but because it is the user type most commonly related to data breaches and most directly implicated in Experience Cloud's current threat landscape. This isn't hypothetical. Over the past year, a threat actor claims to have compromised hundreds of organisations by exploiting exactly this gap, and Salesforce has published its own guidance addressing the pattern directly. The technical detail is at the end of this article; the short version for now is that the exposure was never a platform flaw, it was guest user configuration.

Throughout this article I focus on information that may be relevant to the security of your site and in doing so may brush over information relevant to the types of users, for example when considering functionality or scale, the intent of this article is not to cover everything, but to provide a grounding for future articles I may write about security in Salesforce Experience Cloud.

Part 1 - Who is using your site?

Broadly, there can be four categories of users on an Experience Cloud site:

Employees (internal to the company)
B2B users (external to the company)
B2C users (external to the company)
Guest users (external to the company)

Employees

Company employees accessing an Experience Cloud site fall into two patterns. Either the site serves them directly for a business purpose (an employee self-service portal, for instance) or they're interacting with external users to deliver or support the service the site provides (case workers, account managers, support agents working cases raised through the portal, or involved in conversations with external users).

B2B users

Business-to-business users are typically partners of your business: suppliers, channel sales, business customers, or any other relationship where the other party is itself an organisation rather than an individual.

B2C users

Business-to-customer (sometimes referred to as business-to-consumer) users are your customers: the archetypal "portal" user most people picture when they hear the word.

The B2B/B2C line is a spectrum, not a binary

In practice, what one organisation calls a partner, another calls a customer. Rather than a hard boundary, there are a handful of traits that tend to move along a range.

Trait	B2B End	B2C End
Trust	Higher, from an established commercial relationship	Lower, often self-registered and unverified
Data sensitivity	More commercially sensitive data (pricing, deal data, roadmaps)	Typically less commercially sensitive
PII exposure	Often lower	Often higher, with more personal data per user
Control	Higher, since a closer commercial relationship gives you more leverage over user behaviour	Lower, with limited ability to enforce behaviour
User volume	Lower	Higher, and volume itself compounds risk, both statistically and reputationally

Treat this as a spectrum when threat modelling a given site, not as a direct lookup table. A "partner" site with self-registration and thousands of unvetted members behaves more like the B2C end regardless of what you call it.

Guest Users

'Guest user' is Salesforce's term for anyone accessing the site without being logged in (sometimes called 'anonymous' or 'un-authenticated'). In plain terms, an unknown member of the public.

Guest use cases fall into two buckets:

Deliberately anonymous access: public pages and functionality intended for unauthenticated visitors. Reading faculty bios on a university site, finding the nearest store on a retail site, reporting a broken streetlight on a local authority portal.
Pre-authentication access: anyone who hasn't logged in yet is a guest user until the moment they do. This includes visitors on login and self-registration pages.

The second bucket matters because it's easy to forget: your login and self-registration pages are guest-accessible surfaces. It's important to remember that every Experience Cloud site has a guest user associated with it, regardless of what your guest user use-case is.

Part 2 - Technical traits

External Users

External users (B2B and B2C) are users associated with Community Cloud licenses such as Customer Community, Customer Community Plus and Partner Community. They share some structural traits distinct from internal users:

They always have an Account and a Contact associated with the User record. (There's an exception involving Salesforce Identity users, which I'll set aside here.)
Where the Account is a Person Account rather than a business Account, the Account and Contact are effectively merged into a single record. Worth knowing when you're reasoning about sharing, since sharing rules and OWD still operate on the underlying Account/Contact model (with less options) even though the UI and application layer treat it as one thing.
Their org-wide default is set separately from internal users, in the External OWD column on the sharing settings page, a distinct setting from the internal OWD for the same object.

External users come in two technical flavours:

Role-based (or "advanced sharing") users. These use the platform's standard sharing mechanisms: sharing rules, groups, manual shares, Apex-managed sharing. Salesforce's own documentation is inconsistent about naming this category, you'll see "role-based" in some places and "advanced sharing" in Experience Cloud-specific docs for the same thing.

High-volume users, configured via sharing sets. This is a schema-relationship-based sharing mechanism evaluated at runtime rather than pre-computed into sharing tables. It's built for scale, since pre-computing and searching sharing for millions of users isn't practical. High-volume users deserve their own article when it comes to scale and configuration; for security purposes, three points matter:

Sharing is configured through sharing sets, not through the standard sharing UI, so an audit that only reviews sharing rules and public groups will miss this population entirely, and so will most off-the-shelf security health tooling (AppExchange packages and custom-built dashboards alike), which is typically built around the standard sharing model.
Record-level access is determined at runtime rather than precomputed, which is a performance/architecture distinction more than a security one, but explains why these users don't show up in the usual sharing-rule tooling.
High-volume users still respect External OWD. What's different is how access beyond that baseline gets granted.
Because High-volume users are not part of the role hierarchy, implicit sharing associated with role hierarchies does not apply.

Sometimes in conversation Salesforce refers to these users as 'high volume portal users' aka 'HVPU users'.

Internal Users

Internal users are ordinary Salesforce Users. They have a User record, but an associated Account and Contact are optional, unlike external users, where both are mandatory.

Part 3 - Salesforce guest user

I've covered what guest users are from a use-case perspective: untrusted, unverified identity, and arguably the category carrying the most business risk in a breach. There are three personas related to this:

The general public: the visitor you designed the site for. Reading content, using intended anonymous functionality.
The not-yet-authenticated member: someone who will shortly become a trusted external user, about to login, or about to register, but is a guest user until they do.
The attacker: anyone probing the site's public surface for what it exposes. Nothing about the platform's configuration distinguishes this persona from the first two at the point of request; the access granted to "the public" is, by definition, also granted to this persona.

Multiple experiences, but one user and profile

Every guest visitor to a site shares the same User record and the same profile. So why doesn't every anonymous visitor see identical pages?

The answer splits in two:

View state differs. Each visitor has their own session, and what pages render are session-scoped, not shared between visitors.
Data access does not differ. Object, field, and record-level access is identical for every guest visitor, because it's governed by one shared User record and Profile. You won't see what another guest visitor is doing, but you have access to exactly the same data they do.

"Different visitors see different things" is true at the view-state level, but can create a false sense that data access is somehow personalised or scoped per guest; it isn't. Every guest visitor to a site, whether the general public, a not-yet-authenticated member, or an attacker, is working with the same access rights and the same data visibility.

Guest OWD

Internal OWD and External OWD are the two columns on the Sharing Settings page. Prior to the major guest user changes Salesforce made some years ago, guest user came under the External OWD; now it does not.

Imagine a third column on that same table, one salesforce doesn't show you and one you can't edit, permanently set to Private. That's effectively how guest OWD behaves: forced Private on every object, including objects that don't even display an External Access setting on the Sharing Settings page.

The only lever that grants a guest anything above that locked Private floor is a guest user sharing rule, a criteria-based rule type built specifically for this. Everything a guest visitor can see traces back to one of those rules (with the exception of Custom Apex Controllers, which can ignore declarative security settings).

Record Ownership

Prior to Salesforce's guest user security changes, a guest user could end up as the owner of records they created. Imagine a multi-step, unauthenticated onboarding flow that saves progress to a record as the visitor moves through it. Alice (a guest) is reading and writing 'state' data as part of an onboarding wizard. Meanwhile, Eve is using that same shared Guest User account. Whether by accident or on purpose, she can read and write Alice's in-progress record too, because as far as the platform is concerned, they're the same owner.

Salesforce has since closed this: guest users can no longer own records. Ownership transfers to a nominated or programmatically determined non-guest user once the create transaction completes.

There are edge cases relating to historical data created before this change took effect, which are documented by Salesforce in 'Reassign records owned by guest users'.

The Guest User Record (and Profile) always exists

It's also worth being clear that the existence of a guest user record (and profile) doesn't depend on whether you intended to use it. Every Experience Cloud site provisions a Guest User record and a Guest User profile the moment the site exists, regardless of whether "Public Access" is switched on, and regardless of whether anyone on your team thinks of the site as having guest users. A site that's internal-only in intent, or fully gated behind login, still has a Guest User profile sitting in the org with whatever access it was given. The platform doesn't offer an option to not have one.

Summary

A guest user is potentially anyone (or any automated process) that has access to the Internet.

Every Experience Cloud site has a Guest User record and profile from creation, whether or not you intended to allow guest access.
Guest access isn't governed by External OWD. It's separate, locked by default (forced private on every object). Only a guest user sharing rule can override this (with the exception of code).
The Guest User is one profile shared by three different visitor personas: 'the general public', the 'not yet authenticated', and an attacker probing what the site will hand over. Whatever one can see, all the others can see.
High-volume (sharing-set) external users don't appear in standard sharing-rule audits or some security health tooling. A clean sharing-rules review doesn't mean a clean org.
A B2B partner site and a B2C customer site can carry identical technical exposure if the underlying sharing configuration is the same. The business label doesn't set the control level, the configuration does.
This isn't theoretical. Overly permissive Guest User configuration is the documented mechanism behind large-scale Experience Cloud breaches in 2025 to 2026 (see below).

About the ongoing security advisory 20000244

A threat actor, reported by BleepingComputer and others to be the group ShinyHunters, ran a modified version of the open-source Aura Inspector tool (originally built by Mandiant, now part of Google, as a way for admins to find their own misconfigured sites) to "perform mass scanning of public-facing Experience Cloud sites," exploiting overly permissive guest user settings to query CRM data without ever logging in.

ShinyHunters itself has claimed roughly 100 high-profile organisations compromised this way. BleepingComputer notes the group has elsewhere put the total as high as 300 to 400. In March 2026, Salesforce published a trust security advisory and guidance addressing the issue directly, stating that "malicious actors are exploiting customers' overly permissive Experience Cloud guest user configurations to potentially access more data." The platform wasn't the vulnerability, the Guest User configuration was.