Experience Cloud & Security

An Experience Cloud guest user is an internet-facing identity—not a free licence

JSBC Labs4 October 20268 min read

Anonymous traffic still has an identity

An Experience Cloud visitor may never sign in, but Salesforce does not execute the visit without context. Public access runs through the site's guest user and its profile, record access, enabled Apex classes and exposed components. Thousands of unknown visitors can therefore exercise one shared security principal from the public internet.

That changes the design question. The guest user is not a convenient way to avoid licences or registration; it is an application identity with the broadest possible audience. The JSBC Labs position is that every permission granted to it should be reviewed like an unauthenticated API capability: explicit purpose, minimum authority, constrained inputs, observable outcomes and a named owner.

Define the public capability before configuring permissions

Teams often begin in the guest profile, enabling objects and classes until a page works. That bottom-up approach makes the final access model difficult to explain. Start with a capability statement instead: a visitor can read approved knowledge, submit a support request or begin an application. State the records, fields and operations required for that journey—and nothing else.

Separate genuinely public functions from those requiring identity, consent or an existing relationship. Viewing product information may be anonymous; checking a case, amending personal details or downloading a document usually needs authentication and record-level authorization. If a capability cannot be described without saying ‘the component needs it,’ its permission is probably being driven by implementation rather than business intent.

A guest sharing rule is a publication rule

Salesforce enforces private org-wide defaults for guest users. Guest users cannot receive record access through manual sharing or Apex managed sharing; read access is opened through guest user sharing rules. Those rules are criteria based and read only. This is a protective baseline, but it does not make a broad criterion safe.

Treat every matching record as published to anyone who can reach the site. Use a dedicated, immutable publication flag or similarly narrow criterion rather than a convenient status shared with internal processes. Check related objects and files separately. Include records from every region, business unit and historical period in the review, because a rule that looks harmless against today's sample can expose tomorrow's data automatically.

Permission layers are cumulative

A page can touch several independent controls: object permissions, field access, record sharing, Apex class access, Flow permissions and component configuration. Removing one layer may break the page, but granting one does not automatically secure the others. A record shared read-only can still reveal a field the public journey never needed; an enabled Apex class may query a wider dataset than the UI displays.

Build a guest-access matrix by capability. List each object, readable or creatable field, record-selection rule, Apex class, Flow and file path. Link every entry to a screen or server operation. Review the matrix after releases and managed-package changes. Salesforce recommends highly restrictive guest profiles and no object access for almost all objects; exceptions should remain small enough for a reviewer to understand completely.

System context is a trust-boundary crossing

Custom Apex and some automation can perform work with authority beyond the caller's ordinary object and field permissions. That can be necessary for a public form: the visitor supplies limited input while trusted server logic creates or updates a controlled record. It is also where a harmless-looking page can become an elevation path into internal data.

Mark every system-context operation as a privileged boundary. Accept a purpose-built request rather than an arbitrary sObject, allowlist writable fields, validate values and re-query only the records the operation is permitted to touch. Declare sharing behaviour deliberately and use user-mode operations or explicit security enforcement where the capability should respect the guest principal. Never rely on hidden buttons or client-side field removal as authorization.

Assume the browser is controlled by an attacker

Public users can change JavaScript, replay network calls, alter identifiers and invoke server operations without following the visible screen. Salesforce's forms decision guide warns that client-side orchestration can be inspected and modified, including calls to Integration Procedures, Data Mappers and Apex. A well-designed interface improves usability; it does not constrain a hostile client.

Revalidate every assumption on the server. Do not trust hidden values, record IDs, prices, ownership, status or sequencing supplied by the page. Bind server actions to the narrow public use case and return only necessary data. Use generic failure responses where detailed errors would reveal record existence or internal structure, while retaining sufficient protected diagnostics for the support team.

Creation needs ownership and abuse design

A public form may legitimately create a lead, case or custom intake record. Decide the default owner, required fields, duplicate behaviour, assignment path and downstream automation before granting create access. Never let a guest choose privileged owners, internal statuses or relationship IDs. Treat every supplied value as untrusted, even when the page uses a picklist.

Design for automation and integration amplification. One small submission can trigger Flows, emails, callouts, platform events and expensive matching logic. Add appropriate anti-automation controls, input limits and operational thresholds at the public edge. Make processing idempotent where retries are possible, and give operations a way to quarantine suspicious submissions without deleting evidence or blocking legitimate customers.

Files create a second exposure path

Upload and download requirements deserve their own threat model. A guest-submitted file can contain malicious content, sensitive personal data or a filename designed to mislead an operator. A public download can expose more than its parent record if ContentDocument links, libraries or sharing are configured broadly. Record access and file access are related, but they are not interchangeable.

Constrain accepted types and sizes, scan or quarantine content where the risk requires it, and avoid presenting untrusted files directly to internal users. Use generated references rather than predictable identifiers. Verify who can retrieve the binary before and after record reassignment. Retention, deletion and consent rules should cover the file itself, not only the form record that points to it.

Test from the outside in

Administrator testing is almost useless for proving guest isolation. Test in a private browser with no Salesforce session, then exercise the underlying network requests directly. Change record identifiers, omit fields, add unexpected fields, repeat submissions and request records that do not match the public criteria. Confirm that failures do not reveal whether protected data exists.

Automate negative tests for every public server operation and include permission changes in release review. Salesforce Well-Architected guidance recommends penetration testing for custom applications exposed to untrusted users, especially Experience Cloud sites and public APIs. Retest after new objects, fields, Flows, packages and site features are introduced; public exposure changes even when the page design does not.

Operate guest access as a security product

Assign one accountable owner for the site's public attack surface. Review guest profile permissions, sharing rules, class access and public components on a fixed cadence. Monitor unusual submission rates, validation failures, repeated identifiers and downstream automation volume. Keep a rapid containment plan that can disable a public capability without taking every authenticated community journey offline.

Salesforce supplies strong guest-user restrictions, but configuration and custom code decide what the internet can actually do. A safe public site is not the result of one checkbox. It is a maintained contract between business intent, least privilege, secure server behaviour, testing and operations. When the guest identity is treated as production infrastructure, anonymous experiences can remain useful without becoming invisible doors into the org.