Home / security / guest-user-security-audit

guest-user-security-audit

Audit Experience Cloud guest user access — object/field CRUD, sharing, login, and hardening. Triggers: guest user audit, Experience Cloud guest security, site guest profile. NOT for member/community user provisioning — use admin/experience-cloud-member-management. NOT for profile/permset architecture — use admin/permission-sets-vs-profiles.

v1.0.0
Salesforce Spring '25+
Updated 2026-05-05
Security
Reliability

guest-user
experience-cloud
secure-by-default
owasp-a01
access-control

Open the skill folder on GitHub

Guest User Security Audit

Experience Cloud sites can serve unauthenticated visitors via the Guest User. Historically the Guest User was provisioned with broad permissions on by default, leading to a class of public-data- exposure incidents that hit the press through the late 2010s. The Spring '21 secure-by-default release locked this down: object- level permissions are off by default, Modify All / View All are removed, sharing rules are required to grant any record access, and the platform actively warns when a configuration would expose data.

This skill is the audit playbook. It walks the standard surfaces where guest data leakage happens and the OWASP Top 10 mapping for each.

What changed in Spring '21

Before Spring '21	After Spring '21 (secure by default)
Guest profile could grant View All Data	Removed; cannot be granted
Guest profile could grant Modify All Data	Removed
Guest profile could grant Manage Users	Removed
Object permissions on by default	Off by default
Implicit access via OWD	Sharing rule required
Guest could update other users' records	Blocked unless explicit sharing rule + record ownership rules

Orgs that existed before Spring '21 do not auto-migrate. They inherit grandfathered permissions until an admin removes them. The audit's first job is identifying grandfathered permissions still active.

The leakage surfaces

Even with secure-by-default, leakage can still happen through:

Guest profile permissions still granted by an admin since
Spring '21 (the platform allows some grants, just with warnings).
Apex with without sharing runs as the guest user but
bypasses sharing — guest can read records they shouldn't.
@AuraEnabled Apex methods exposed to LWC / Aura — the
guest user's session can call them; they execute with the sharing mode of the class (with sharing / without sharing / default inherited sharing).
REST endpoints under /services/apexrest — Apex REST
classes exposed publicly inherit the same sharing rules; default without sharing is dangerous.
Public Visualforce / Sites pages — older feature; still in
use; same sharing concerns as Apex.
Sharing rules granting access to records owned by guest —
the platform restricts these in modern orgs but legacy configurations may still exist.

Standard audit surfaces

Surface	Question to ask	Tool
Guest profile permissions	What object / system permissions are still granted?	Setup -> Profiles -> Guest User -> Object / System Permissions
Sharing rules granting to guest	Which records are shared to the guest user?	Setup -> Sharing Settings; Object's Sharing Rules; filter Type = 'Guest user'
Apex sharing mode	Which Apex classes are `without sharing`?	Static analysis / `ApexClass.Body` SOQL
@AuraEnabled methods	Which Apex methods are callable from LWC / Aura?	ApexClass with `@AuraEnabled` annotations
Apex REST endpoints	Which classes expose REST?	Apex with `@RestResource(urlMapping=...)`
Public site visibility	What pages / endpoints are reachable without login?	Setup -> Sites; Run-As-Guest test

OWASP Top 10 mapping

The dominant risk class is A01: Broken Access Control. Guest user mis-grants are textbook A01. Secondary: A03 Injection (if guest-callable Apex constructs SOQL/SOSL from input), A05 Security Misconfiguration (default permissions left on), A07 Identification and Authentication Failures (insufficient guest session controls).

Recommended Workflow

Enumerate Guest Users. Each Experience Cloud site has its own Guest User. List them via Setup -> All Sites -> per-site -> Public Access Settings (which is the per-site Guest profile clone).
Audit each Guest profile's permissions. Object permissions, system permissions, FLS. Modern target: zero object permissions unless explicit need; zero View All / Modify All (these should already be blocked by secure-by-default but legacy grants need removal).
Audit sharing rules with Type = 'Guest user'. Each rule should map to a documented business justification. Anything granting "all records" of a sensitive object is a finding.
Static-analyze Apex. Find classes with without sharing. Cross-check whether they are reachable by guest (called from @AuraEnabled method or @RestResource exposed to public site).
Run-As-Guest the site. Setup -> Users -> Guest User -> Login. Walk every component on every page; capture network requests. Anything returning data that shouldn't be public is a finding.
Validate REST and Aura/LWC endpoints separately. Use a tool / manual probe to call @AuraEnabled and Apex REST endpoints with no auth and see what returns.
Prioritize remediation. Findings that expose PII or regulated data go first. Findings that expose internal configuration go second. Map each to OWASP A01 / A03 / A05 in the report.

What This Skill Does Not Cover

Topic	See instead
Authenticated Experience Cloud user mgmt	`experience/experience-cloud-user-management`
General profile / permset design	`admin/profile-permset-design`
Apex security at large (CRUD / FLS)	`apex/apex-with-sharing-patterns`
Encrypted fields and Shield Platform Encryption	`security/shield-platform-encryption`