CRUD/FLS checks on fields of a lookup

Question

We have a Salesforce public site where we expose name fields of Account and Contact object. These fields are queried through a lookup of Account and Contact on a custom object. Like this:

[Select Id, Account__c, Account__r.name, Contact__c, Contact__r.name from Custom_Object__c]

For this query we applied Read access on Account(Name), Contact(FirstName, LastName) and Custom Object.

Problem is client can not provide Read access on Account and Contact object to guest user, it is too much of access. Other option is to remove Read access checks from Account/Contact object and from Name field of them but will it create issue during Salesforce security review?

In general, Is it okay if we just check the read permission on lookup field on custom object and remove the access checks from fields which are referred through that lookup.

What are other alternatives?

Answer 1

There are often situations where there's a one-off use case where a user persona needs access to data but they shouldn't have blanket access to those objects/fields via OLS/FLS.

When reviewing the code from a security perspective static analysis tools such as PMD are often used. If it is really appropriate in this case for the Guest User to have access to this data (but they shouldn't have Profile / Permission Set based access to the fields across the board), you could do the following

1. Add a NOPMD suppression comment that explains why OLS/FLS is not enforced on the particular query. This helps security reviewers understand why you made the decision and evaluate whether or not it's safe. For example

   // NOPMD: Specific CRM data is displayed to the Guest User in this case, but is limited in scope using query filters. Guests should not have Profile-level access to these objects.

2. Evaluate the situation as a whole to make sure the reasoning around the exception being secure is sound. Check out the sharing defaults and which records could potentially be displayed to the guest. Remember that some fields on Account/Contact can in some cases represent business/competitive information or PII

If this query is flagged during security review, be open to reconsidering the finding in case there really is a security issue that needs to be addressed there.

If you are certain it is a false positive, and have justification for it being secure, you can respond as false positive (see ISV Guide: Responses to False Positives)

Answer 2

The main way to avoid leaks in the current system is to use Security.stripInaccessible. Using this ensures that you will not be in violation of Security Review problem.