The Salesforce Security review require that both:
- Object Level (OLS)
- Field Level (FLS)
Security is applied for the following areas:
- Query of data – Selectors
- Triggers – Domains
- 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 |
- 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.
Thys Michels Blog 