4

I recently checked my managed package using the Force.com Security chechker (by Checkmarx) and the tool listed a few CRUD and FLS issues in my Controller classes.

Before fixing them I tried to better understand why they are needed and used my pages as different users

  • that are unable to write certain objects modified by the page (CRUD)
  • that are unable to see certain fields shown on the page (FLS)

I expected the page to just ignore my permission settings but it did not!

The fields without FLS were not shown on the page nor where they read by my SOQL code. The same with CRUD. When the page tried to save a read-only object the trigger reported an exception which nicely displayed in the page messages.

So my question is: Why do I need explicit FLS and CRUD checks if Salesforce seems to perfectly respect the permissions?

Improve this question
4
  • 2
    The <apex:inputField> and <apex:outputField> tags will enforce these permissions, but they are not the only way to surface fields.
    – Adrian Larson ♦
    Mar 28, 2017 at 13:58
  • 1
    You mention a trigger. How did it know to fire? Would seem there was a CRUD check being performed of some kind. Is this perhaps a false positive? Those things do happen with Checkmarx. You just have to be able to explain why and where it occurred.
    – crmprogdev
    Mar 28, 2017 at 14:39
  • I am using the FinancialForce Apex Commons library. Maybe it does CRUD checks. Let me verify that @crmprogdev.
    – Robert Sösemann
    Mar 29, 2017 at 7:21
  • 1
    I know it has those capabilities Robert. @AndrewFawcett utilizes them in his book. It's all a matter of how you wrote your code to call various domain services using the recommended patterns.
    – crmprogdev
    Mar 29, 2017 at 12:23

1 Answer 1

Reset to default
1

The explanation for the page to not ignoring your permission when seeing it, is likely what Adrian Larson states in the first comment.

However, the explanation for you DMLs resulting in errors when you are not enforcing CUD (note that you are still missing checking the FLS, which should be done) is probably just because of the fact that you are using fflib_SObjectDomain for having a trigger in the same SObjectType upon you are performing the DML against.

It is not really performing the CUD check before the DML happens, only in the trigger, so if you perform a DML upon a SObjectType wich does not have a trigger associated (or has one, but does not extend fflib_SObjectDomain), then, your user permissions will likely be ignored

Improve this answer

You must log in to answer this question.

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