Security has and will always be a concern for any organisation especially when there are multiple roles and hierarchies. You may want to restrict or extend the data accessibility to an individual or a group of users but security can be a big challenge but not anymore with APEX. It helps to enforce security.

In this blog we are going to explore the security model Salesforce provides to maintain data accessibility among varied roles and users.

Level of Data Access: It defines how, and which users will have access to what data in the org – a specific object, a specific field or a specific record:

Organization: Maintain a current list of users, updated password policies and restrict IP login ranges.

Object level security: Object level access to specific data to groups of users.

Field level security: Restrict access to specific fields, even if user has access to the object.

Record level security: Allow some users to access object, but limit which records they can
view/create or modify.Record-level access can be managed in four ways-

1.OWD –Organisation Wide Defaults can be set to Public or Private for each standard and custom object.
2.Role hierarchies –Setup roles and hierarchies and grant access accordingly.
3.Sharing rules –Automatically share records with an individual or group of users.
4.Manual sharing –Manually share a record with an individual or group of users.

The data hidden via above security and sharing settings does not applies to apex code i.e Apex code uses different sharing settings. Therefore, Apex code security and applying the sharing rule is most important.

To enforce above mentioned level of data access on Apex code use following keywords to

1.With Sharing

●If class is declared with “With Sharing” keyword, then sharing rules configured for the current user will be taken into consideration.
●The user can access and perform the operations based on permissions given to him on objects and fields
●The Apex code executed with the Anonymous call and Chatter in Apex, always uses full permissions of the current user.

Syntax –

public with sharing class “Your class name” {
// Code here

2.Without Sharing

●If class is Without Sharing, then this apex class runs in system mode
●Apex code has access to objects and fields irrespective of sharing rule, field level security & object permissions set for current user

Syntax –

public without sharing class “Your class name” {
// Code here

3.Unspecified Sharing

●If a class is not declared using any sharing keyword, then class knows unspecified sharing.
●Sharing of class with this type of declaration is determined by the caller class. See example below:

Suppose Class A is with Sharing, Class B is Without Sharing and Class C is Unspecified Sharing then,

1.Class A is a caller of Class C then Class C enforced with Sharing.
2.Class B is a caller of Class C then Class C enforced without Sharing.
3.Class C is not called by any class then Class have default unspecified sharing.

●If there is a custom component associated with the controller used by a Visualforce page, then security is only checked for the controller associated with the page

4.Inherited Sharing
●Inherited sharing enables you to pass security review and ensure that your privileged Apex code is not used in insecure ways.
●An Apex class with inherited sharing runs similar to a class with “With Sharing” when used as:
-Aura component
-Visualforce controller
-REST service
-Any other entry points
●A class with inherited sharing runs similar to a class with “Without Sharing” when class is called from any without sharing context.

Inner /Outer class Sharing

●The sharing setting applies to all code contained in the class when both inner and outer classes are declared with sharing.
●Inner class Sharing is independent of Outer class means it does not inherit from outer class.

On this note, I am signing off now. Don’t forget to check out our Co-Founder’s previous blog on SALES.

Written by- Komal Patil

Leave a Reply

Close Menu