Portal & Experience Cloud Security Quick Reference

Fast-track reference for portal and Experience Cloud security — the area where CTA candidates most often apply internal security patterns incorrectly. External users have fundamentally different sharing, licensing, and hierarchy behaviors. Know these differences cold.

External License Comparison

License	Objects	Reports/Dashboards	Role Hierarchy	API Access	Sharing Model	Cost Tier	When to Use
Customer Community	Cases, Knowledge, custom	No	Flat (1 role)	No	Sharing sets (HVCP)	Lowest	Self-service portals, B2C, high-volume
Customer Community Plus	Standard + custom	Yes	3 levels (Exec/Mgr/User)	Limited	Standard sharing + rules	Medium	Customers needing reports, hierarchical access
Partner Community	Sales objects + custom	Yes	3 levels (Exec/Mgr/User)	Yes	Standard sharing + rules	Medium-High	Channel partners, resellers, co-selling
External Apps	Custom objects primarily	No	Flat (1 role)	Yes (optimized)	Sharing sets (HVCP)	Lowest	API-heavy integrations, branded apps
External Identity	None (auth only)	No	None	No	None	Very Low	SSO/login only, no Salesforce data access
Channel Account	Sales objects	Yes	3 levels	Yes	Standard sharing	Per-account bundle	Multiple contacts per partner account
Guest User	Only what rules grant	No	None	Disabled by default	Guest sharing rules only	Free	Public-facing pages, unauthenticated access

Board Technique — License Selection

Always state the license choice AND the rejected alternative: “I chose Customer Community over Community Plus because the 200K users do not need reporting, and the flat hierarchy keeps sharing computation low at scale. If the client later needs hierarchical visibility, we can upgrade individual users without re-architecting.”

External OWD Rules

External OWD is set separately per object and can only be the same as or MORE restrictive than internal OWD.

Internal OWD	Allowed External OWD	Typical Choice
Private	Private only	Private
Public Read Only	Private, Public Read Only	Private (external users should not see each other’s data)
Public Read/Write	Private, PRO, PRW	Private (almost always)

Key rules:

External OWD defaults to matching internal — always review separately
Guest user OWD is always Private and cannot be changed
Changing internal OWD resets external OWD to match — re-check after every change
If ANY two external users from different accounts should not see each other’s records, External OWD = Private

Common Mistake

Candidates forget to set External OWD separately. If Internal OWD is Public Read Only and you do not change External OWD, partner users from Acme can see partner users’ records from Contoso. The board will catch this immediately.

Customer Community and External Apps licenses use High-Volume Customer Portal (HVCP) sharing — a completely separate mechanism from standard sharing rules.

flowchart LR
    subgraph "Sharing Set Configuration"
        SS["Sharing Set"] --> AM["Access Mapping"]
        AM --> TO["Target Object\ne.g., Case"]
        AM --> LF["Lookup on Target\ne.g., Case.AccountId"]
        AM --> UF["User's Account\nContact.AccountId"]
        AM --> AL["Access Level\nRead or Read/Write"]
    end

    subgraph "Runtime Resolution"
        PU["Portal User logs in"] --> Match{"Case.AccountId\n=\nUser's Contact.AccountId?"}
        Match -->|Yes| Grant["Access Granted"]
        Match -->|No| Deny["No Access"]
    end

    SS -.->|"Evaluated at"| Match

    style SS fill:#1565c0,color:#fff
    style Grant fill:#2e7d32,color:#fff
    style Deny fill:#c62828,color:#fff

Feature	Standard Sharing Rules	HVCP Sharing Sets
Used by	Community Plus, Partner	Customer Community, External Apps
Based on	Ownership or criteria	Lookup field match to user’s Account/Contact
Role hierarchy	Participates	Does NOT participate
Share tables	Standard (can bloat at scale)	Separate optimized tables
Scale	Thousands of users	Millions of users
Performance	Degrades with rules + records	Optimized — no hierarchy recalculation
Cross-account access	Sharing rules can grant	Cannot grant cross-account; need different mechanism

Sharing Set Performance at Scale

Sharing sets perform well up to ~10M records per object. Beyond that, evaluate whether the lookup field used in the access mapping is indexed and selective. Complex sharing sets with multiple access mappings on the same object compound the query cost. Monitor with sharing set diagnostics.

Share Groups solve the opposite problem — granting internal users access to records owned by HVCP portal users.

Mechanism	Direction	Example
Sharing Set	Internal records —> External users see them	”Portal users see their Account’s Cases”
Share Group	External-owned records —> Internal users see them	”Support agents see Cases created by portal users”

Share Groups contain sets of internal users (by role, profile, or public group) who should see HVCP-owned records for a specific site.

Guest User Lockdown Checklist

Guest User = Unauthenticated = Highest Risk

Every piece of data visible to guest users is visible to the entire internet. Salesforce has issued multiple critical advisories about guest user misconfigurations leading to data breaches. The board will probe this aggressively.

Check	Action	Status
Object permissions	Remove ALL objects except the minimum needed (e.g., Knowledge, 1-2 custom objects)	Required
Field-level security	Hide every field not explicitly needed; never expose PII fields	Required
API access	Disable — Guest User API Access should be OFF	Required
Apex class access	Remove all except classes explicitly needed for guest flows	Required
Record ownership	Guest-created records go to site default owner, NOT guest profile	Introduced Spring ‘20, enforced without opt-out since Winter ‘21
Sharing rules	Only criteria-based guest user sharing rules; no ownership-based	Enforced since Winter ‘21
View All / Modify All	Cannot be granted to guest users	System-enforced
Connected Apps	Remove guest user from all Connected Apps	Required
Flows / processes	Audit all flows accessible to guest profile — no SOQL without sharing	Required
Health Check	Run Salesforce Health Check; resolve all guest user findings	Quarterly

Portal Role Hierarchy

Portal roles are auto-created per Account when a community user is enabled. They sit beneath the Account Owner’s role in the internal hierarchy.

License Type	Roles Created per Account	Configurable?
Customer Community	1 (User only — flat/HVCP)	No — flat only; configurability of 1-3 levels applies to Community Plus and Partner licenses
Customer Community Plus	3 (Executive, Manager, User)	Number configurable (1-3)
Partner Community	3 (Executive, Manager, User)	Number configurable (1-3)
External Apps	1 (User only — flat)	Number configurable (1-3)

How it differs from internal hierarchy:

Roles are scoped to the Account — users in Account A cannot see Account B’s data via hierarchy
Account Owner (internal user) gets implicit sharing to all portal roles beneath
Role hierarchy can be disabled per object (“Grant Access Using Hierarchies” checkbox)
At scale (100K+ accounts), auto-created roles inflate the role hierarchy — monitor total role count (limit: 5,000 portal roles total org-wide across all portals/communities)

LWR vs Aura Site Security

Aspect	LWR Sites	Aura Sites
Security model	Lightning Web Security (LWS)	Lightning Locker
CSP support	Strict CSP by default	CSP supported
Cross-namespace	LWS allows controlled cross-namespace	Restricted by Locker
New site default	Yes (recommended for new builds)	Legacy — still supported
SEO / performance	Better (static rendering)	Slower (client-side)

LWR for New Sites

As of 2025-2026, Salesforce recommends LWR for all new Experience Cloud sites. LWR uses Lightning Web Security (LWS) instead of Lightning Locker, providing better performance and stricter isolation. Choose Aura only if you have existing Aura components that cannot be migrated.

Reverse-Engineered Use Cases

Scenario 1: Partner Portal — 50K+ Channel Partners

Situation: Global manufacturer with 50,000 partner users across 2,000 partner accounts. Partners register deals, access co-branded marketing, and view their pipeline. Partners must NOT see other partners’ data. 15 internal channel managers need to see all partner data.

What you’d present:

License: Partner Community (need reports, sales objects, deal registration)
External OWD: Private on Account, Opportunity, Lead, custom Deal Registration object
Portal role hierarchy: 3 levels per account (Executive sees all reps’ deals within their company)
Sharing rules: None cross-account — Private OWD + hierarchy handles intra-account visibility
Internal access: Channel Manager role sits above all partner roles via implicit sharing
Deal Registration: Apex managed sharing to grant read access to the assigned internal rep

Why NOT Customer Community Plus: Partners need Sales objects (Opportunities, Leads) and deal registration workflows. Community Plus supports this but Partner Community includes partner-specific features (Lead assignment, deal registration, channel programs).

Scenario 2: Customer Self-Service with Sensitive Health Data

Situation: Healthcare company, 500K patients access lab results, appointment scheduling, and billing. HIPAA compliance required. Patients should see only their own data. No cross-patient visibility.

What you’d present:

License: Customer Community (high volume, no reporting, self-service only)
HVCP sharing sets: LabResult.PatientAccountId = User.Contact.AccountId (Read Only)
External OWD: Private on all objects (enforced — HIPAA)
Guest user: Completely locked down — only Knowledge articles with IsPublished = true shared via guest sharing rule; no PII fields on guest profile
Shield Platform Encryption on PHI fields (lab results, diagnosis codes)
Person Accounts for patient records (each patient = Account + Contact)
Share Group: Internal care team role added to share group so providers can see patient-created Cases

Why NOT Community Plus: 500K users at Community Plus pricing is cost-prohibitive. Patients do not need reporting, dashboards, or hierarchical visibility. HVCP sharing sets scale to millions and avoid share table bloat.

Gotchas

Guest User API Access

Guest user API access is disabled by default since Spring ‘21. If your architecture requires an unauthenticated API endpoint (e.g., public form submission), use a Site.com page with an Apex controller running without sharing scoped to a single object — and justify this explicitly at the board.

License Upgrade Path

Upgrading from Customer Community to Customer Community Plus is NOT a simple license swap. It changes the sharing model from HVCP (sharing sets) to standard sharing (rules + hierarchy). This means all sharing sets stop working, new portal roles are created per account, and sharing rules must be written. Plan this as a migration, not a config change.

Role Hierarchy Bloat

With 3 portal roles per Account and 10,000 Accounts, you have 30,000 auto-created roles. Salesforce supports up to 500 portal roles per Account, but total role count impacts sharing recalculation time. For high-account-count deployments, reduce roles to 1 per Account (configurable in Community Settings).

Portal & Experience Cloud Security Quick Reference

External License Comparison

External OWD Rules

Guest User Lockdown Checklist

Portal Role Hierarchy

LWR vs Aura Site Security

Reverse-Engineered Use Cases

Scenario 1: Partner Portal — 50K+ Channel Partners

Scenario 2: Customer Self-Service with Sensitive Health Data

Gotchas

Deep Dive References

Sources

Portal & Experience Cloud Security Quick Reference

External License Comparison

External OWD Rules

HVCP Sharing Sets

Share Groups (Reverse Direction)

Guest User Lockdown Checklist

Portal Role Hierarchy

LWR vs Aura Site Security

Reverse-Engineered Use Cases

Scenario 1: Partner Portal — 50K+ Channel Partners

Scenario 2: Customer Self-Service with Sensitive Health Data

Gotchas

Deep Dive References

Sources