Newer Version Available
Using the with sharing, without sharing, and inherited sharing Keywords
With Sharing
Use the with sharing keyword when declaring a class to enforce sharing rules of the current user. Explicitly setting this keyword ensures that Apex code runs in the current user context. Apex code that is executed with the executeAnonymous call and Connect in Apex always execute using the sharing rules of the current user. For more information on executeAnonymous, see Anonymous Blocks.
Use the with sharing keywords when declaring a class to enforce the sharing rules that apply to the current user. For example:
1public with sharing class sharingClass {
2
3 // Code here
4
5}Without Sharing
Use the without sharing keyword when declaring a class to ensure that the sharing rules for the current user are not enforced. For example, you can explicitly turn off sharing rule enforcement when a class is called from another class that is declared using with sharing.
1public without sharing class noSharing {
2
3 // Code here
4
5}Inherited Sharing
Use the inherited sharing keyword when declaring a class to enforce the sharing rules of the class that calls it. Using inherited sharing is an advanced technique to determine the sharing mode at runtime and design Apex classes that can run in either with sharing or without sharing mode.
Using inherited sharing, along with other appropriate security checks, facilitates in passing AppExchange security review and ensures that your privileged Apex code isn’t used in unexpected or insecure ways. An Apex class with inherited sharing runs as with sharing when used as:
- An Aura component controller
- A Visualforce controller
- An Apex REST service
- Any other entry point to an Apex transaction such as an asynchronous Apex class.
There’s a distinct difference between an Apex class that is marked with inherited sharing and one with an omitted sharing declaration. If the class is used as the entry point to an Apex transaction, an omitted sharing declaration runs as without sharing. However, inherited sharing ensures that the default is to run as with sharing. A class declared as inherited sharing runs as without sharing only when explicitly called from an already established without sharing context.
Example
1public inherited sharing class InheritedSharingClass {
2 public List<Contact> getAllTheSecrets() {
3 return [SELECT Name FROM Contact];
4 }
5}1<apex:page controller="InheritedSharingClass">
2 <apex:repeat value="{!allTheSecrets}" var="record">
3 {!record.Name}
4 </apex:repeat>
5</apex:page>Implementation Details
- The sharing setting of the class where a method is defined is applied, not of the class where the method is called from. For example, if a method is defined in a class declared as with sharing is called by a class declared as without sharing, the method executes with sharing rules enforced.
- If a class isn’t explicitly declared as either with sharing or without sharing, the current sharing rules remain in effect. Therefore, the class doesn’t enforce sharing rules except when it acquires sharing rules from another class. For example, if the class is called by another class that has sharing enforced, then sharing is enforced for the called class.
- Both inner classes and outer classes can be declared as with sharing. Inner classes do not inherit the sharing setting from their container class. Otherwise, the sharing setting applies to all code contained in the class, including initialization code, constructors, and methods.
- Classes inherit sharing setting from a parent class when one class extends another.
- Apex triggers can’t have an explicit sharing declaration and run as without sharing.
- Asynchronous Apex classes defined with inherited sharing always run in with sharing mode for asynchronous operations. Each asynchronous operation is a new entry point and the sharing mode is not serialized.
Best Practices
Apex without an explicit sharing declaration is insecure by default. We strongly recommend that you always specify a sharing declaration for a class.
Regardless of the sharing mode, object-level access and field-level security are not enforced by Apex. You must enforce object-level access and field-level security in your SOQL queries or code. For example, with sharing mechanism doesn’t enforce user’s access to view reports and dashboards. You must explicitly enforce running user’s CRUD (Create, Read, Update, Delete) and field-level security in your code. See Enforcing Object and Field Permissions.
| Sharing Mode | When to Use |
|---|---|
| with sharing | Use this mode as the default unless your use case requires otherwise. |
| without sharing |
Use this mode with caution. Ensure that you don’t inadvertently expose sensitive data that would normally be hidden by the sharing model. This sharing mechanism is best used to grant targeted elevation of sharing privileges to the current user. For example, use without sharing to allow community users to read records to which they wouldn’t otherwise have access. |
| inherited sharing | Use this mode for service classes that have to be flexible and support use cases with different sharing modes while also defaulting to the more secure with sharing mode. |