8

Does the Modify All Data or View All Data permission allow a user/profile to ignore the FLS settings for an object? The documentation would seem to suggest that this is the case, but I've found conflicting results.

Using Schema.SObjectField.getDescribe().isUpdateable() to perform a FLS check will return return false if the 'Edit' permission isn't granted for the field. This behavior holds while running as a user with the View All Data or Modify All Data permission.

This would seem to indicate that FLS is independent from the Modify All Data and View All Data permissions. However, I can write a unit test that runs as a user with the Modify All Data and successfully perform an update to the field that the FLS check said wasn't updatable.

Improve this question

3 Answers 3

Reset to default
22

Modify All Data and View All Data do not, in any way, affect Field Level Security. The only permission that affects Field Level Security is Edit Read Only Fields. Apex Code generally ignores Field Level Security, while Visualforce generally honors Field Level Security. This is the reason why the "isAccessible" calls are available. The "with sharing" and "without sharing" keywords refer to record visibility and record editablity, not field accessibility.

Improve this answer
4

It's worth noting that apex does not enforce field level security, even if run with sharing. Typically visualforce handles enforcement of these for you by doing things like not rendering apex:inputField or apex:outputField tags referencing a field the user has no FLS access to.

This automatic enforcement of FLS is only done at the presentation layer by the platform, enforcing it within apex contexts must be done explicitly in your classes (with isAccessible(), isUpdatable(), etc) if you want it to be done at all.

Thus regardless of the running user's access to a field your apex tests would be allowed to read and write said field.

Improve this answer
3
  • Good point--this is the reason I'm writing security checks for my APEX code in the first place. I thought using the RunAs() method would enforce user permissions, but it's simply running the code under a specific user or profiles context.
    – cseaton
    Mar 16, 2014 at 23:34
  • @csnullptr runAs does, or at least should, enforce running user's permissions. If it's not I'd classify it as a platform bug (of which I've stumbled into a couple when using runAs)
    – ca_peterson
    Mar 16, 2014 at 23:36
  • 1
    It does enforce sharing permissions! FLS is something you check. Think of Apex Code like Workflow rules. They can modify fields users have no access to, but not records the user has no access to.
    – sfdcfox
    Mar 17, 2014 at 0:30
-1

Yes, this is one of the reasons that I normally ratchet down all record access and functionality for ALL users to start with and then "build up" based upon their requirements (leveraging profiles, roles, permission sets and sharing rules). This normally starts by removing MAD and VAD.

For me the only exception to this would be some form of Administrator account.

Some security options such as MAD and VAD are quite often too powerful and I shy away from using them.

Improve this answer

You must log in to answer this question.

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