SalesforceSummaries: a series delivering key insights from Salesforce YouTube videos, to save you time as you keep up to date with the latest technological changes within the Salesforce ecosystem.
Introduction:
In this presentation, a quick review of how the Salesforce security model will be presented. Then, an overview on how Apex code runs followed by best practices that you should adopt to ensure your Apex code is secure from a field level security perspective.
Details: ‘Your Apex Code and the Salesforce Security Model’
Presenter: Matt Quagliana
Details: 18 minutes
Key Terms: Apex code, security model, field level security, indirect reference
1.@1.50 — Every Salesforce user is assigned a Profile. Profiles determine the base CRUD (create, read, update, delete) access for different Salesforce objects (sObjects).
2.@2.20 — Profiles in Salesforce also determine read/write access to fields. This is known as field level security (FLS).
3.@2.40 — Permission sets enable you to extend access to other users without having the need to create more Profiles.
4.@3.20 — Org Wide Defaults (OWD) determine access for records where you are not the owner.
5.@4.10 — Roles extend ownership. If your manager needs to see/edit your records, then this can be achieved via the role hierarchy.
6.@4.40 — Another important Salesforce security feature is sharing rules. Sharing rules also extend access to certain groups.
7.@5.40 — Contacts inherit the security settings from the account. And if you have contacts that aren’t related to an account, then that contact is private (only the owner has access to the account).
8.@7.40 — In summary, there are a number of different features that can be leveraged in Salesforce confirmatively to determine who can see and do what in the application. Crucially, all declarative configuration runs inside the user context. Meaning, that it runs within the bounds of all these settings and rules.
9.@8.00 — However, with regards to Apex code, this is slightly different. There are some special variations to point out when it comes to Salesforce security with Apex.
The most important distinction is that Apex runs in the system context and not the user context. Furthermore, in some situations, Apex lets you decide how to handle security.
10.@8.50 — Controllers are typically how you get access to data from Apex code. It is not best practice to use an indirect reference as this is a way in which data could be leaked.
11.@10.05 — An example of an indirect reference is line 11 in the code example below.
There is nothing in this code which ensures that people who should not have access to the value from the ‘Favorite_Color__c’ field do not see it.
12.@11.00 — The way to resolve this is, as per line 10, to add a single test. The isAccessible() method from the Schema sObject can be used to test whether a user has access to any object and/or field.
13.@11.40 — You should only write code for requirements that configurations cannot handle. Being able to leverage isAccessible() is helpful because you may want to write logic to say that ‘these sets of users can only access these sets of fields during business hours, and/or these sets of users can only access these sets of fields if these fields on the same record are of a certain value’.
14.@13.00 — Adopting the with sharing keywords make your custom code respect OWD, role hierarchy and sharing rules.
15.@14.10 — The best practices are:
Leveraging apex:inputField conforms to field level security etc whereas apex:InputText does not.
- @15.20 —
- @16.10 — The official guidance from Salesforce is below. This link has some great information.
- @17.20 — In summary,
Also, these trailhead modules are very informative on this particular topic too:
