Salesforce Summaries – Your Apex Code and the Salesforce Security Model

Share this article...

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

[email protected] — Every Salesforce user is assigned a Profile. Profiles determine the base CRUD (create, read, update, delete) access for different Salesforce objects (sObjects).

[email protected] — Profiles in Salesforce also determine read/write access to fields. This is known as field level security (FLS).

[email protected] — Permission sets enable you to extend access to other users without having the need to create more Profiles.

[email protected] — Org Wide Defaults (OWD) determine access for records where you are not the owner.

[email protected] — Roles extend ownership. If your manager needs to see/edit your records, then this can be achieved via the role hierarchy.

[email protected] — Another important Salesforce security feature is sharing rules. Sharing rules also extend access to certain groups.

[email protected] — 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).

[email protected] — 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.

[email protected] — 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.

[email protected] — 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.

[email protected] — 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.

[email protected] — 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.

[email protected] — 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’.

[email protected] — Adopting the with sharing keywords make your custom code respect OWD, role hierarchy and sharing rules.

[email protected] — The best practices are:

Leveraging apex:inputField conforms to field level security etc whereas apex:InputText does not.

  1. @15.20 —

  1. @16.10 — The official guidance from Salesforce is below. This link has some great information.

  1. @17.20 — In summary,

Also, these trailhead modules are very informative on this particular topic too:

Leave a Reply