Salesforce Object Level and Field Level Security Architecture

The Salesforce Security review require that both:

  1. Object Level (OLS)
  2. Field Level (FLS)

Security is applied for the following areas:

  1. Query of data – Selectors
  2. Triggers – Domains
  3. DML – Unit of Work

To check both (OLS) and FLS we can use fflib_SecurityUtils it has all the to methods to check if a user can access an object and also individual fields for that object. An Apex exception is thrown if the user does not have access to the given object and/or fields.

Example is when a community user tries to create an Account the following error occurs if OLS is enabled

fflib_SecurityUtils.CrudException: You do not have permission to insert Account
Class.fflib_SecurityUtils.checkObjectIsInsertable: line 309, column 1
Class.fflib_SObjectUnitOfWork.insertDmlByType: line 583, column 1
Class.fflib_SObjectUnitOfWork.doCommitWork: line 531, column 1
Class.fflib_SObjectUnitOfWork.commitWork: line 509, column 1
Class.App_Service_Test.testSecurityUOW: line 81, column 1

  1. Query of data – Selectors

The key purpose of this class is to make building dynamic SOQL queries safer and more robust than traditional string concatenation or String.format approaches. It also has an option to automatically check read security for the objects and fields given to it. Here are some of the methods we use to dynamically build all our queries.

Enable FLS check for queries before they run, by setting setEnforceFLS(true)

OR set the OLS and FLS when constructing a new Selector so it will be implement for all queries

OpportunitiesSelector oppsSelector = 
new OpportunitiesSelector(includeFieldSetFields, enforceObjectSecurity, enforceFLS);

2. Triggers – Domains

Domain classes has minimal functionality in it other than the routing of trigger events to the applicable virtual methods and object security enforcement.

Domain classes by OLS by default as part of it’s Configuration class:

3. DML – Unit of Work

This is not currently implemented to check the following:

1. Insert

  if (enforceOLS){
       fflib_SecurityUtils.checkObjectIsInsertable(sObjectType);
  }

2. Update

 if (enforceOLS){
       fflib_SecurityUtils.checkObjectIsUpdateable(sObjectType);
  }


3. Delete 

if (enforceOLS){
     fflib_SecurityUtils.checkObjectIsDeletable(m_sObjectTypes[objectIdx--]);
  }

Disadvantages of OLS and FLS implemented across your app

OLS – this is a check that is done to see if the user profile has access to do CRUD on the specific object. If this check is not done and user tries to do any of the CRUD operations it will just result in a Salesforce error. Doing this check on an object level is not too big of an overhead. If these checks are not done, Permission errors will be thrown as the profile does not have the correct permission.

FLS – this is not recommended as we have to iterate through every field of the object and check if the user has the privileges to read/update/insert/delete to that field. This slows down operations down drastically and only needs to be used in a few uses cases.

Possible solutions run security checks on app

Have a way to enable both OLS and FLS in your code then run through all your test and see if any break. If the break GREAT fix your Object Settings/FLS so that they work. When running in Production have a way to disable this as it may/will slow down your operations/services.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: