How to deal with the security of odd standard fields?

Question

We are using the Security.stripInaccessible method to identify fields that don't have the proper DML permission to insert, update etc. It works good for the most part but it gives us some false positives that we need to handle afterwards.

Here are post Security.stripInaccessible checks that we do to identify the inaccessible fields:

fieldDescribe.getType() != DisplayType.ADDRESS // Filters out compound address fields
fieldDescribe.isPermissionable() // Filters out (most) system fields and master-detail lookups on the child
!fieldDescribe.isCalculated() // Filters out formula fields

I'm fine with these checks since they are dynamic and don't require our intervention. The thing that really bothers me though is the following fields:

• System fields that we have not found a way to identify them using Apex: LastReferencedDate, LastViewedDate
• The clone field that causes some test cases to fail only when packaging (I can't access this field using the Schema function seems like an internal Salesforce field): CloneSourceId
• Standard Contact object checkboxes that are defaulted to hidden by Salesforce I believe even for admins and none of our clients having access to them (Technically not a false positive but still annoying) HasOptedOutOfFax HasOptedOutOfEmail DoNotCall
• I believe enabling Salesforce to Salesforce connection adds these two fields which I also don't know how to filter out: ConnectionReceivedId ConnectionSentId
• The field that breaks in some subscriber orgs but I cannot find: CanAllowPortalSelfReg

Currently, the way we're dealing with this problem is that we maintain a list of "odd" fields and they bypass the security checks function. The problem with this approach is that we have to maintain this list and once in a while deal with service interruption in client orgs.

Ideally, non of our DML calls should have extra fields that aren't being updated but we have a large code base and some dynamic queries grab more than they should.

I'm curious how others are dealing with the issue or if they use something other than Security.stripInaccessible. The optimal solution I'm looking for is something that doesn't require SOQL queries to do the CRUD FLS and also doesn't return too many false positives.

Answer 1

How we do this in our app is to determine if a field is required, then use Security.stripInaccessible to remove inaccessible fields, compare it to our list of required fields, and surface an error only if we're missing a required field, otherwise we just continue as normal with the removed fields. Also, as a practical matter, you should generally make new sObject records in a map or list so that you only update fields that you intend to. You could even make a utility class to handle this in a uniform manner.