Newer Version Available

This content describes an older version of this product. View Latest

Using the with sharing, without sharing, and inherited sharing Keywords

Use the with sharing or without sharing keywords on a class to specify whether sharing rules must be enforced. Use the inherited sharing keyword on a class to run the class in the sharing mode of the class that called it.

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.

Because the sharing mode is determined at runtime, you must take extreme care to ensure that your Apex code is secure to run in both with sharing and without sharing modes.

Warning

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

This example declares an Apex class with inherited sharing and a Visualforce invocation of that Apex code. Because of the inherited sharing declaration, only contacts for which the running user has sharing access are displayed. If the declaration is omitted, contacts that the user has no rights to view are displayed due to the insecure default behavior.
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.