Best Practices and Considerations When Configuring the Guest User Profile

General Best Practices and Considerations

• The guest user profile is specific to the particular Experience Cloud site. Check the guest user profile for each site to ensure data security.
• The browser’s locale settings override the date and time formats configured under Salesforce's locale settings for guest users. Make sure the browser's preferred language is an active translation language; otherwise, the system defaults to the guest user's locale setting.
• As long as the Experience Cloud site is active, guest users can access a subset of its pages, such as login and error pages.
• Use the Authenticated and Guest User Access Report and Monitoring AppExchange package to understand if records are being shared with guest users.
  

  Note

  Salesforce doesn't own or support the Authenticated and Guest User Access Report and Monitoring AppExchange package. If you have troubleshooting issues, contact the package owner.

Sharing Settings

The Secure guest user record access setting limits guest users' visibility and access to your org’s data.

Note This setting is enabled by default and can't be disabled. The timelines for the rollout and enforcement of this setting are published in Guest User Security Policies and Timelines.

When this setting is enabled, guest users:

• Have org-wide defaults set to Private for all objects. This access level can’t be changed.
• Can’t be added to queues or public groups.
• Can’t be given access to records through manual sharing or Apex managed sharing.
• Can be granted Read Only access to records only through guest user sharing rules. Guest user sharing rules are a special type of criteria-based sharing rule and count towards the limit of 50 criteria-based sharing rules per object.
  

  Warning The guest user sharing rule type grants access to guest users without login credentials. By creating a guest user sharing rule, you're allowing immediate and unlimited access to all records matching the sharing rule's criteria to anyone. To secure your Salesforce data and give your guest users access to what they need, consider all the use cases and implications of creating this type of sharing rule. Implement security controls that you think are appropriate for the sensitivity of your data. Salesforce is not responsible for any exposure of your data to unauthenticated users based on this change from default settings.

Object Settings

• Review all default object permissions in the guest user profile, and then apply the most restrictive permissions for the guest user. For almost all objects, we recommend that the guest user has no access. If your business case calls for object data to be exposed to the guest user, set a maximum Read permission where possible.
• Change the Default Record Type. The system Default Record Type is automatically set to Master, but we recommend you select a new record type for any object that a guest user has access to.
• Review the permission set licenses, permission sets, and permission set groups assigned to guest users. Make sure that the permission set licenses don’t entitle guest users to permissions not required for their business needs. Verify that guest users aren’t granted unnecessary permissions via permission sets or permission set groups. In Winter ’23, Salesforce is removing guest user assignments from certain permission sets and permission set groups. Permission set groups and permission sets associated with permission set licenses that contain View All Records, Modify All Records, edit, and delete standard object permissions no longer have guest user assignments. The only object permissions allowed for guest users are read and create. For more information, see Guest User Security Policies and Timelines.
• Enable the Assign new records created by guest users to the default owner setting so that guest users are no longer automatically the owner of records they create.
• Never assign the View All Records or Modify All Records permission to guest users.
• Never assign update or delete permissions to guest users.

System Permissions

• Review all system permissions, and then deselect the permissions that aren’t necessary for your use case.
• Disable the View All Users permission if you don’t want guest users to see other users of the site. The View All Users permission is off by default on guest user profiles in orgs created in Winter ’20 and later.
  

  Note When you deselect View All Users, guest users no longer have access to user or topic feeds in a site.
• If guest users aren’t using flows, disable the Run Flows permission. If guest users need flow access, disable the pause option on flows that guest users are accessing.

API Usage

The API Enabled permission in system permissions lets external applications or connectors use the API to authenticate or access Salesforce data. The Salesforce mobile app is an example of API usage.

• Check if the API Enabled permission is enabled for the guest user profile.
• Salesforce strongly recommends that you disable the API Enabled permission unless guest users explicitly need API access.
• Disable the permission in a sandbox first to see how guest user access is affected.

Visualforce Page and Apex

• Review all Visualforce and Apex pages that guest users can access. Remove pages that you don’t want guest users to access.
• The following Salesforce-provided Visualforce pages are added by default to the guest user profile to provide common services, such as authentication flows or site maintenance.
  • BandwidthExceeded
  • CommunitiesLanding
  • CommunitiesLogin
  • CommunitiesSelfReg
  • CommunitiesSelfRegConfirm
  • CommunitiesTemplate
  • Exception
  • FileNotFound
  • ForgotPassword
  • ForgotPasswordConfirm
  • InMaintenance
  • SiteLogin
  • SiteRegister
  • SiteRegisterConfirm
  • UnderConstruction
• If your site doesn’t offer self-registration, remove these self-registration pages from your guest profile:
  • CommunitiesSelfReg
  • CommunitiesSelfRegConfirm
  • SiteRegister
  • SiteRegisterConfirm
• Remove all other Visualforce pages unless they support specific business processes (ISV app, custom app).
• Restrict Apex classes for guest users. Allow Apex class access only for REST or SOAP API use. Apex classes that serve as Visualforce controllers don’t need explicit access.
• In Apex class and subclass code, look for record updates or queries that don’t check field-level security or object permissions or are in "without sharing" classes. Keep Apex and subclass code that runs without sharing or bypasses field-level security and object permissions to a minimum.
• If a guest user can execute an @AuraEnabled method in an Apex controller used by a Lightning component, always use the “with sharing” keyword.
• Add guest user profile access to any @AuraEnabled Apex class used by an Experience Cloud site.

Data Category Settings

• If Classic Knowledge is implemented in your org, check data category settings to ensure that guest users can access all the Salesforce Knowledge categories that you want them to.

Field-Level Security

• Review the field-level security of objects that guest users can access to ensure that they have access to the correct fields.
• Remove field-level access to fields that you don’t want guest users to see.

Event Sync

If you use Einstein Activity Capture or Lightning Sync to sync events, follow these guidelines to make sure that guest users don’t have access to event data.

• Don’t invite guest users to events.
• Don’t use the same email address for a guest user and a non-guest user. Doing so could result in the guest user being added to events.
• Turn off the Access Activities permission on the Guest User profile unless access is necessary for your use case.
• If a guest user owns an event, delete or reassign the event.
• If a guest user is an invitee on an event, remove them from the organizer's event record. Or, if the event isn’t part of a series, use the API to delete the relevant EventRelation record. If the event is part of a series, use the API to delete the guest user from the UndecidedEventInviteeIds, AcceptedEventInviteeIds, or AcceptedEventInviteeIds field on the Event object.
• If events sync from Salesforce to the connected account or in both directions, keep in mind that changes made to Salesforce events can trigger notifications to be sent to all attendees.