Salesforce Guest User Security Testing
Salesforce guest user security testing validates what an unauthenticated visitor can reach through a public Experience Cloud site or Salesforce Site. Every site has one guest user and one guest user profile, and anything that context can read, create or invoke is effectively available to the internet. Testing proves the guest reaches only what the site is meant to publish — and nothing behind the login.
Authenticated customer and partner members are covered separately on Experience Cloud security testing.
What the guest user context is
When someone visits a public page on a site without logging in, Salesforce runs their requests as that site's guest user. The guest user has a dedicated guest user profile, managed from the site's settings, that holds its object permissions, field-level security, Apex class access, Visualforce page access and enabled flows. Anyone who can reach the site's URL inherits exactly that access, with no identity, no session history and no accountability attached.
Salesforce applies stricter rules to guests than to any other user. With secure guest user record access, the external org-wide default is enforced as Private for guest users, guests cannot be granted access through manual sharing or the role hierarchy, and guest sharing rules — a dedicated criteria-based sharing rule type — can grant read-only access only. Records a guest creates are assigned to a default internal owner rather than to the guest.
Those guardrails narrow the problem but do not remove it. Object create permissions, guest sharing rules with broad criteria, custom Apex, flows and files can all open paths the platform defaults do not close for you. Guest user security testing treats the guest as a first-class persona and tries every one of those paths deliberately. For the logged-in portal audience, see Experience Cloud security testing.
Common guest exposure paths
These are the configuration choices that most often give a public visitor more than the site owner intended.
Broad guest sharing rules
A guest sharing rule written to publish active products can also match draft, internal or discontinued records if its criteria are loose, making them readable by anyone.
Object permissions on the guest profile
Read or create rights granted to support a single web form apply to the whole object, including through data calls the form never makes.
Apex exposed to the guest profile
An Apex class enabled for the guest profile that is declared without sharing, or queries in system mode, can return records guest sharing never granted.
Flows running in system context
A screen flow on a public page that runs in system context without sharing can look up or update records well beyond the guest's own rights.
Files and public links
Content delivered through public links or attached to publicly shared records can be retrieved by anyone who holds or guesses the link.
Member and user visibility
Site settings that let guest users see other members of the site can disclose names and profile details of your customers and staff.
Why guest exposure goes unnoticed
Almost nobody tests as a guest. Site builders work in Experience Builder as authenticated internal users, user acceptance testers log in to check their journeys, and page previews run with rights far wider than a real visitor has. The guest context is exercised mainly by real visitors — and by anyone probing the site deliberately.
The second reason is that the visible site is not the full attack surface. A public page that shows three product fields may be backed by a component whose server call can return every field the guest profile can read. Removing the component from the page does not remove the Apex class from the guest profile. Because nothing errors and the page looks correct, the gap between what is displayed and what is reachable stays invisible.
Finally, guest configuration is rarely revisited. A guest permission added for a campaign landing page or a one-off registration form tends to remain long after the page is retired, and every later object or field added to the org is judged against a guest profile that nobody is watching.
Guest surfaces and their deny assertions
Each surface a guest can touch gets an intended outcome and a deny assertion that proves the boundary holds.
| Guest surface | Intended outcome | Deny assertion |
|---|---|---|
| Public record pages | Only records matched by guest sharing rules are viewable | A record ID outside the rule criteria returns no data |
| Public web forms | Guest can create the intended record type with intended fields | Guest cannot read back other submitted records or set restricted fields |
| Knowledge and content pages | Articles published to the public channel are readable | Internal and partner-channel articles are not returned by search or URL |
| Apex-backed components | Server methods return only the published fields and records | Calling the method with other parameters returns nothing beyond guest access |
| Public flows | Flow completes its intended lookup or submission | Flow cannot be driven to read or update records outside its purpose |
| Search on the site | Search returns only publicly shared objects | Search for known internal record names yields no results |
| Files and attachments | Intentionally published files download | Files on internal records cannot be retrieved without a valid public link |
How to test a site as its guest user
These tests belong in a sandbox copy of the site, run by the team that owns it, using known seeded records.
Inventory the guest profile
Export the guest user profile's object and field permissions, enabled Apex classes, Visualforce pages and flows for every active site, and note each one's purpose.
List guest sharing rules
Record every guest sharing rule, its object and criteria, and the records it is intended to publish, so the intended guest audience is explicit.
Seed sentinel records
Create internal-only records designed never to be public, including values that would be easy to spot if they leaked, alongside records that should be published.
Browse as an anonymous visitor
Load each public page with no session and confirm published content appears, forms submit and flows complete as designed.
Exercise the data layer directly
Replay the component and flow requests a public page makes with altered record IDs and parameters, asserting sentinel records and restricted fields never return.
Trim and re-test
Remove unused guest permissions in the sandbox, re-run the suite and confirm the published experience still works on the narrower profile.
Guest user scenarios to automate
A compact regression pack for a public site typically includes the following checks.
- An anonymous visitor submits a contact-us or registration form and the new record is owned by the site's default owner, not left accessible to the guest.
- A guest cannot read back a submitted case, lead or application by altering the record ID in a confirmation URL.
- Draft or archived knowledge articles do not appear in public search or article lists.
- A product catalog component returns only products matched by the guest sharing rule, even when asked for a product ID outside it.
- An Apex method used by a public page returns no results when called with an internal account or contact ID.
- Guest users cannot see a member directory or user profile details when that visibility setting is meant to be off.
- A public flow that looks up an order by reference number returns nothing unless both the reference and a verification value match.
- After a site page is retired, the Apex classes and flows it used are no longer enabled for the guest profile.
Evidence for security and privacy reviews
Public exposure questions usually come from security, privacy and compliance teams. A guest suite gives them proof rather than configuration screenshots.
What is public, stated explicitly
The inventory of guest permissions and guest sharing rules, each tied to its purpose, documents the intended public footprint of every site.
Proof of the deny side
Retained results show sentinel records and internal fields were attempted as the guest and blocked on each run.
Change history
Run-over-run results show when the guest footprint changed and which release or deployment introduced it.
What SyntraFlow is designed to do
SyntraFlow is designed to run scenarios in an unauthenticated context and retain the evidence, available for demonstration and proof-of-concept validation.
Keeping guest access tight after releases
Salesforce has repeatedly tightened guest defaults through release updates, and it continues to adjust site and sharing behavior in seasonal releases. That is good for security but can break public pages that relied on older behavior, so the guest suite should run against a sandbox preview org before each release reaches production — confirming both that published content still works and that nothing new became public.
Between releases, trigger the guest suite whenever the guest user profile, guest sharing rules, site pages or any Apex class or flow enabled for guests changes. Health Check and Security Center style reviews highlight risky settings; guest user security testing complements them by proving what a visitor can actually reach. Fold the suite into the wider security regression testing cadence so public access is re-proven every time the org moves.
Related pages
Salesforce security testing
The hub for validating access by persona across users, integrations and guests.
Experience Cloud security testing
Validates the logged-in customer and partner members of the same sites.
Negative access testing
The deny-case method behind every guest boundary assertion.
Experience Cloud testing
Functional testing of the public pages and journeys guests use.
Customer registration testing
Tests the moment a guest becomes a registered site member.
Security regression testing
Re-proves guest access after each change and seasonal release.
Guest User Security Testing testing FAQs
What is Salesforce guest user security testing?
It is the validation of what an unauthenticated visitor can reach through a public Salesforce site. Tests run as the site's guest user and prove that only intentionally published records, fields, flows and files are reachable, while internal data stays blocked even when requests are altered.
Can guest users edit records in Salesforce?
Guest sharing rules grant read-only access, and secure guest user record access prevents guests from being given record access through manual sharing or the role hierarchy. Guests can still create records where the guest profile allows it, and custom Apex or flows running in system context can update records, which is why those paths need explicit tests.
Why test beyond what the public page displays?
A page only shows what its components choose to render. The Apex methods and flows behind those components can often be called with different parameters, and any record or field they return is exposed. Testing the data layer directly is the only way to confirm the reachable footprint matches the visible one.
How is this different from Experience Cloud security testing?
Guest testing covers the single anonymous context each site has. Experience Cloud security testing covers licensed, logged-in customers and partners, whose access comes from sharing sets, portal roles and member profiles rather than guest sharing rules.
Does Salesforce Health Check replace guest user testing?
No. Health Check and similar reviews score configuration against recommended settings. They do not exercise your specific guest sharing rules, Apex classes and flows against your data. Guest user security testing complements those reviews by proving what a visitor can actually retrieve.
Know exactly what your public sites expose
See how guest user security testing proves unauthenticated visitors reach only what you chose to publish.