Every public Experience Cloud site works through a guest user — an unauthenticated context with a real profile and real object grants. That is by design, and it is fine — until the grants accumulate past what the public site was meant to show.
How exposure happens without anyone deciding it
A component needs one object readable, so the grant is added. A form needs create on another. A troubleshooting session in 2022 adds read on a parent object “temporarily.” Guest sharing rules widen things further. No single step was wrong; the sum is an unauthenticated surface nobody has reviewed as a whole. Salesforce itself has been tightening guest defaults since Winter ’21 — hard-restricting guest writes — precisely because this accumulation pattern kept producing incidents.
The review that works
List the guest profile’s object grants and read the list as a persona: should an anonymous visitor reach this object at all? Write-class grants deserve immediate scrutiny. Then review guest sharing rules alongside — access is the union. And re-check after site changes, because the grants drift.
Horus Eye files one finding per guest profile, mechanism-graded — critical when any write-class grant survives, high for read — while saying plainly what the scan cannot judge: whether each object belongs in your public persona. That call stays yours; the evidence shouldn’t take a week to assemble.
The five checks worth running today
First, the guest user profile itself: object permissions on every custom object, because defaults drift and clones inherit. Second, guest sharing rules — the only supported way guests see records — checked against what each rule actually exposes rather than what its name implies. Third, the org-wide Secure guest user record access setting, which should be on everywhere and verified after sandbox refreshes. Fourth, Experience site page access: builder pages published to unauthenticated users can expose components whose data access is wider than the page design suggests. Fifth, files and attachments — a record a guest can see may carry files nobody meant to publish.
Why this drifts
Guest access rarely breaks loudly; it widens quietly. A component added for a portal feature, a sharing rule written for a campaign and never retired, a permission granted during an incident and forgotten. That is why the review belongs on a calendar, not a to-do list: a short, recurring pass over those five surfaces, with each finding either fixed or explicitly accepted in writing. The accepted list matters as much as the fixes — it is what turns next quarter’s review from archaeology into a diff.
The bottom line
Guest access is the one part of your org whose users you will never meet and whose mistakes you will read about last. The five surfaces above fit in a recurring half-day review; the alternative fits in an incident report. If your Experience site has been live for more than a year and nobody has read the guest profile since launch, schedule the half day this month.
