Why did I fail Security Review when not checking FLS or using “without sharing”?

Question

I submitted a package for security review which has a Custom Object which has internal / technical semantics only. So it's not created or even seen by users. When a user performs some action some "with sharing" classes insert, update and delete such objects.

The Security Review rejected this as "HIGH RISK CRUD and FLS Enforcement" and recommends the usage of Schema.sObjectType.CustomInternalObject__c.isUpdateable(); and the like.

I cannot use those checks as the performing user has no direct access to those objects.

What can I do now? Is this a false positive I can explain? Any hints or experiences to share?

Answer 1

The perfect answer was recently given by MVP Dan Appleman in his article Without Sharing: Best practices when bypassing Apex sharing rules and object security.

Application internal data, Business process code and data transformations are three common scenarios where it is not only possible, but essential to ignore sharing rules, object security and field level security. ...if you implement one of the architectures described here, it’s virtually guaranteed that your first attempt to pass security review will fail.

You’ll need to document exactly what you are doing and why as part of your security review application, but once you’ve done so, assuming your security architecture is sound, you should be able to pass security review, at least with regards to field, object and record level security, without further trouble.

So just ask for a follow-up meeting with the security review team via a Case in the Partner Portal and prepare a written explanation why you had to circumvent the standard security mechanisms in your app. And always argument and reason from a Business case perspective "I wasn't able to implement this customer process without not...!