Guest User Enhancements Overview

For Vlocity security improvements, read Guest User Technical Details.

Who Is Affected

If you have Salesforce Communities or Salesforce Sites, check whether you have enabled Public Access (Guest User). If yes, you are affected by these changes and need to understand the details.

What’s the Problem

The guest user was intended to access public information in a customer’s site and maybe generate some public data, such as public message posts, chat, Q&A, public information search, knowledgebase, etc.

But as customer implementations and Vlocity started using the guest user for anonymous journeys that require capturing user information in Salesforce ( such as e-commerce, quotes, sales, etc.), security required additional custom capabilities. These capabilities included API gateways and the complex management of org-wide defaults that affected both authenticated external users and the guest user.

Important

Understanding the security problems is essential to ensure you implement a secure solution when using the guest user.

The guest user profile has two security gaps:

• The same user — From a Salesforce point of view, all guest users are the same user.

• Sequential ID — Salesforce IDs are sequential and can be guessed.

As a result, a hacker can access other guest user records if the implemented API is not designed securely. If you implement an API (Apex REST or remote access) that a guest user can call and you rely only on CRUD and sharing rules for security, you won’t be able to secure this data. So, a guest user will have access to all guest user data as they are the same user from a Salesforce point of view.

What Salesforce is Doing

Salesforce is closing the two security gaps of the same user profile and sequential IDs.

Same User— Salesforce is enforcing the "least privilege" principle.

• The guest user profile has a separate organization-wide default (OWD) from external users, and it will be always private.

• Guest users can’t own any record and can’t access any record by default.

• Guest users can create records but can’t read, update, or delete records by default.

Sequential ID — Salesforce recommends the "reduce attack surface" principle.

• Use a single entry point for record access (setter/getter).

• Salesforce recommends (but does not enforce) that developers encrypt and decrypt the IDs.

  • This is where customer’s implementation requires attention and should follow the recommended best practices because encryption and decryption are the responsibility of the customer's implementation.

  • Several Vlocity APIs have been updated in Spring '20 Minor Release to follow these best practices. But, since they are used with custom APIs, Vlocity also exposes a UserSecurity classUserSecurity Class to help you manage the encryption and decryption.

• Another option is to add a custom field in the objects that are required for the guest user and to generate a secure non-sequential ID. (For example, use the Crypto.GenerateAESKey and encode as hex or URL safe.) Then, only use this new secure ID instead of the encrypted record ID. This would be more performant, scalable, and easier to manage and code than the using encryption/decryption in all API because the hit is only when creating a new record. But the Vlocity APIs (such as the Cart-based or Digital Commerce APIs) still require the encrypted ID to work as Vlocity follows the Salesforce recommended solution.

After the updates, Salesforce still can’t differentiate guest users. As a result, any privilege given to a guest user applies to all guest users. The ID encryption prevents a guest user from accessing other guest user's records. Sharing rules do not prevent access but, in fact, grant access.

"Any record modification needs for Guest Users should be addressed by executing such updates in Apex methods that reside in classes running in ‘without sharing’ mode, coupled with encryption/decryption of resources. This approach has been deemed most secure by Salesforce."