When you allow guest users access to read record data, you expose your data to the public. Review our guidelines, and design your implementation to allow the necessary access to guest users without compromising your data.
The Summer ’20 release added new settings and updated guidelines for guest user record access. As of Winter ’21, the guidelines introduced with the Summer ’20 update are enforced. After the Winter ’21 release, use one of the methods described in this document because the previous methods no longer work.
Note
Each time a guest user requests to read record data, the response runs in a mode that determines if sharing rules apply to the request. Because the modes have different security implications, consider the sensitivity of your data to determine the safest method for your business needs. You can also use separate flows or multiple Apex classes to run some requests in one mode and other requests in another mode.
How to Treat Sensitive Information
Remove all sensitive information from records before returning data to an unauthenticated user. For security reasons, don’t use guessable information like record IDs to retrieve records that contain sensitive information.
With Sharing
A record request that runs with sharing can’t access records unless sharing rules give the guest user access to them. Consider sharing rules for read-only access if these scenarios are true:
You want to make the records public and accessible by anyone.
The target records can be selected with sharing rules without exposing other records.
Without Sharing
When you implement requests without sharing, design the requests and the response data carefully to ensure that you don’t unintentionally expose your org’s sensitive data.
Note
A record request that runs in system mode without sharing performs actions with system-level access and bypasses sharing rules. If you aren’t careful about the actions it performs and how it performs them, the request can expose or modify record data when run without sharing. A query that runs without sharing exposes all selected records to the public.
Consider system mode without sharing if any of these scenarios are true:
Your guest users need more than read-only access for the records.
You don’t want the records to be public.
You can’t select the records without exposing other records.
The target records are part of a parent-child relationship and access to the child records is limited by write access on the parent records. Because sharing rules can’t give write access to guest users, run the request without sharing in this scenario.
Encrypted Record IDs for Record Selection
If a guest user creates a record and must access it later, encrypt the record ID with the record creation timestamp, and return the encrypted string to the client. Provide the guest user with a URL that contains the encrypted string so they can avoid typing the long string. When they request read access to the record, retrieve the encrypted string from the URL. To select the record, use the decrypted record ID.
Lightning Components
Lightning components that link directly with an object’s fields automatically perform object create, read, updated, and delete (CRUD) permission and field-level security (FLS) checks to determine whether the components display for the user. For records that you don’t share with guest users, the CRUD and FLS checks fail, and the components don’t display. To use Lightning components to display those records, set their values to variables, and separately associate those variables with the object’s fields in Apex code.
Because this method works around the automatic CRUD and FLS checks, implement your Lightning components with these guidelines:
In your queries, include only the record fields that you need.
Don’t pass sensitive fields to the client-side code.
Pass only fields that the client requires to the client. All data sent to the client is public.
j