Guest User Security Audit

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

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:

1. Guest profile permissions still granted by an admin since Spring '21 (the platform allows some grants, just with warnings).
2. Apex with without sharing runs as the guest user but bypasses sharing — guest can read records they shouldn't.
3. @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).
4. REST endpoints under /services/apexrest — Apex REST classes exposed publicly inherit the same sharing rules; default without sharing is dangerous.
5. Public Visualforce / Sites pages — older feature; still in use; same sharing concerns as Apex.
6. 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

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

1. 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).
2. 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).
3. 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.
4. 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).
5. 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.
6. 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.
7. 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