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?

  • What do you mean that the user has no internal access to the object but your performing CRUD on the object. Are you doing so with a wrapper class that the user acts upon on your page?
    – greenstork
    Commented Jun 13, 2014 at 13:37
  • @greenstork: The code is triggered by a user inserting, updating or deleting a UserCustomObject_c. For each such object we add a "user hidden" technical "InfrastrcutureCustomObject__c" as a lookup related child. Commented Jun 13, 2014 at 14:30
  • 1
    I'm sure they are scrutinizing the fact that you are subverting permissions on that object and controlling it in apex, hence the suggestion for the describes.
    – greenstork
    Commented Jun 13, 2014 at 15:36

1 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...!

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .