Salesforce Experience Cloud Security Testing
Salesforce Experience Cloud security testing validates what authenticated customer and partner users can reach through a site or portal. It proves that external org-wide defaults, sharing sets, share groups, partner roles and member profiles combine so each external persona sees its own account's data — and never another customer's records, internal-only objects or fields the portal was not built to publish.
This page covers logged-in external members; the unauthenticated visitor context has its own guide on guest user security testing.
What Experience Cloud access actually depends on
An external user on a Customer Community, Customer Community Plus or Partner Community license is still a Salesforce user. Their access is the combined result of a profile, permission sets, object and field permissions, and a record-sharing model that is separate from the one your employees use. The external org-wide default for each object sets the starting point, and it can be more restrictive than the internal default but never more open.
On top of that baseline, access is widened in ways that are specific to external users. Customer Community users are high-volume users with no role, so they receive records through sharing sets that match an account or contact lookup on the record to the user's own account or contact. Customer Community Plus and Partner users do have roles, which sit beneath the partner or customer account and can open up records through role-based sharing rules and, for partner executives, upward visibility across the account's portal roles.
Site membership is the final gate: only profiles and permission sets added as members of a site can log in to it. Because each of these controls is configured in a different part of Setup, the only reliable way to know what a portal user can reach is to log in as that persona and exercise it. This page focuses on that authenticated external context; the unauthenticated side is covered on guest user security testing, and internal record visibility on sharing rule testing.
The controls that govern external access
Each of these can grant or withhold access on its own, so each needs both a positive and a deny assertion for every external persona.
External org-wide defaults
Set the floor of record visibility for external users per object. A value accidentally aligned with a Public Read Only internal default exposes every record of that object to every portal user.
Sharing sets
Grant high-volume Customer Community users access to records whose account or contact lookup matches their own. A mapping to the wrong lookup field quietly shares the wrong records.
Share groups
Let records owned by high-volume users be shared with internal users and other external users. An over-broad share group can make one customer's cases visible to another.
Partner and customer roles
Customer Community Plus and Partner users get portal roles under their account. Role-based sharing rules and the executive, manager and user role levels decide who sees colleagues' records.
Site membership
Only member profiles and permission sets can log in to a site. A profile added to the wrong site, or a self-registration default profile with extra rights, widens the audience at once.
Object and field permissions
External profiles and permission sets still control CRUD and field-level security. A sensitive internal field granted for a reporting need becomes readable through the portal's API calls.
How portal access fails without an error
The most common Experience Cloud misunderstanding is treating page and component visibility as a security control. Hiding a record list with audience targeting or removing a tab from site navigation changes what is drawn on screen; it does not change what the user can query. If the underlying object, field or record is accessible, a Lightning component, a record page URL typed by hand or a direct call to the site's Aura endpoint can still return it.
Custom code is the second silent gap. A Lightning web component backed by an Apex controller declared without sharing, or one that queries in system mode without WITH USER_MODE or stripInaccessible, can return records and fields the portal user has no right to see. The page looks exactly as designed during user acceptance testing because testers use their own well-behaved account data.
The third is drift in account structure. When a contact moves to a different account, when a partner account is merged, or when a sharing set is edited to add a new object, visibility changes for every external user tied to those records. None of these changes produces a warning, and none is visible from the customer's side unless they happen to notice another company's data — which is exactly the incident security testing exists to prevent.
External persona matrix
A practical suite starts with one test persona per external access pattern, each paired with records owned by a second, unrelated account so the deny side can be proven.
| Persona | Should reach | Must not reach |
|---|---|---|
| Customer Community user, Account A | Own cases, own contact, Account A's assets via sharing set | Account B's cases, internal-only case fields, other contacts' personal data |
| Customer Community Plus user, Account A | Records shared through role-based sharing rules for Account A | Records of other customer accounts at the same portal role level |
| Partner user | Own leads and opportunities, deal registrations they submitted | Other partner accounts' pipeline, internal discount and margin fields |
| Partner executive | Records owned by manager and user roles under the same partner account | Records owned by executives of a different partner account |
| Partner super user or delegated admin | Create and manage users for their own account only | Resetting or editing external users of another account |
| Newly self-registered user | The default self-registration profile's intended objects | Any object granted only to verified or upgraded member profiles |
| Contact moved to Account B | Account B's records after the move | Account A's records that sharing sets previously exposed |
An Experience Cloud security testing workflow
The workflow mirrors the hub's access-validation sequence, adapted for external licenses and site-specific entry points.
Inventory sites and member profiles
List every active site, its member profiles and permission sets, its self-registration default profile and whether partner or customer roles are in use.
Seed two isolated accounts
Create paired accounts, contacts and child records so every positive assertion for Account A has a matching record in Account B to attempt and deny. See sandbox seeding.
State intended access per persona
Record which objects, fields and record sets each external persona should reach, and which it must not, as the baseline every result is measured against.
Run positive tests through the site
Log in as each persona through the site URL and confirm the pages, lists and actions they need all work — so portal functionality is not broken by over-tightening.
Run deny tests beyond the UI
Attempt direct record URLs, list views, global search and the data calls that site components make, asserting the other account's records and restricted fields never return.
Change the account structure and re-run
Move a contact, change a partner role or edit a sharing set in a sandbox and confirm access follows the change in both directions.
Scenarios worth automating first
These scenarios cover the portal exposures that most often reach production unnoticed.
- Customer user from Account A opens a case record ID belonging to Account B by URL and receives an access error, not the record.
- Knowledge articles restricted to internal channels do not appear in portal search results or article lists.
- A custom Lightning component that lists orders returns only the logged-in user's account orders, including when its Apex controller is called directly.
- Partner user cannot see internal fields such as cost, margin or approval comments on a shared opportunity, even when the field is on an internal page layout.
- Files attached to a case are visible to the case's own customer but not to other external users who share a group or role level.
- A deactivated partner account's users can no longer log in to the site, and their open records remain inaccessible to other partners.
- Self-registration assigns the intended default profile and account, as covered end to end in customer registration testing.
- Case creation through customer self-service writes only the fields the portal form is meant to set.
Evidence and what SyntraFlow is designed to do
These capabilities are available for demonstration and proof-of-concept validation against your own sites and portal configuration.
Log in as the external persona
SyntraFlow is designed to run tests as a real external user on the site, so results reflect the member's effective access rather than an administrator's view.
Paired-account deny assertions
Scenarios can be configured to attempt every positive action against the unrelated account's records and pass only when access is blocked.
Reviewer-ready evidence
Each run can retain the persona, site, record attempted, expected outcome and actual result, giving auditors a record of cross-customer isolation.
Re-run on portal change
The same suite can be triggered when a sharing set, member profile or site component changes, so isolation is re-proven rather than assumed.
Keeping portal security current after releases
Experience Cloud changes more often than most internal configuration. New site pages, new components, new objects added to sharing sets and new partner onboarding waves all move access boundaries. Treat the persona matrix as a living regression pack that runs whenever site metadata, sharing sets or external profiles change, and as part of the wider security regression testing cycle.
Seasonal Salesforce releases also adjust site and sharing behavior, and Salesforce has historically tightened external and guest defaults through release updates. Running the external suite against a sandbox preview org before production upgrades gives you time to adjust. For the broader functional side of portals — navigation, branding and business flows — see Experience Cloud testing; this page stays on who can reach what.
Related pages
Salesforce security testing
The hub for persona-based access validation across every Salesforce access layer.
Guest user security testing
Covers the unauthenticated visitor context that sits alongside logged-in portal members.
Sharing rule testing
Validates org-wide defaults and sharing rules for the internal side of record visibility.
Experience Cloud testing
Functional testing of sites, portals and the business flows external users run.
Partner onboarding testing
Tests the process that creates partner accounts, users and their portal roles.
Negative access testing
The deny-case method used to prove one customer cannot reach another's data.
Experience Cloud Security Testing testing FAQs
What is Salesforce Experience Cloud security testing?
It is the functional validation of what authenticated external users — customers and partners — can reach through an Experience Cloud site. Tests log in as each external persona and prove that external org-wide defaults, sharing sets, share groups, portal roles and member profiles expose their own account's data and block everyone else's.
Is hiding a component with audience targeting enough to protect data?
No. Audience targeting and page visibility control what is displayed, not what the user is permitted to access. If the object, field or record is accessible, it can still be reached through a direct URL, search or the data calls a component makes, so security tests must assert access at the data level.
How do sharing sets differ from sharing rules for portal users?
Sharing sets apply to high-volume Customer Community users, who have no role, and grant access to records whose account or contact lookup matches the user's own. Sharing rules are role- or group-based and apply to users with roles, such as Customer Community Plus and Partner users. Each needs its own tests because a mistake in one does not show up in the other.
How does this differ from guest user security testing?
This page covers logged-in external members with licenses, profiles and record ownership. Guest user security testing covers the single unauthenticated guest user each site has, which follows stricter platform rules and presents a different exposure profile.
Why do Experience Cloud tests need two separate test accounts?
Cross-customer isolation can only be proven by attempting to reach another account's records. Seeding a second, unrelated account with matching record types gives every positive assertion a concrete deny counterpart, so a leaking sharing set or role rule fails a test instead of reaching a real customer.
Can SyntraFlow test partner portals and customer portals in the same suite?
SyntraFlow is designed to model each external license and role pattern as its own persona, so customer and partner personas can live in one suite with shared seed data. The exact sites, licenses and components are aligned to your org during a proof of concept.
Prove every customer sees only their own data
Bring persona-based Experience Cloud security testing to your next portal release and turn cross-account isolation into a passing suite.