---
schema_version: "1"
id: b3f2f74df74c23539c767e6c480ef7ad6008440d6b9b1ff93ea0178a624a393a
title: Apex Security and Sharing Model
collection: legacydeveloper
version: current
locale: en-us
portal_url: https://docs.salesforce.com/legacydeveloper/current/en-us/apexcode/apex_security_sharing_chapter.md
canonical_url: https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_security_sharing_chapter.htm
source_site: developer.salesforce.com
content_type: documentation
content_hash: d041e1acca00877966b5801681fe2d84f356441bc4c60dda7215735726cd4b3b
description: The Apex security model includes record-level, field-level, and object-level security mechanisms. You can control record-level security modes by using the with sharing, without sharing, and inherited sharing keywords on classes. Apex runs in user mode by default, which means that user permissions on objects and field-level security are respected. A user cannot run code that tries to access fields or objects that are hidden from the user. Other security mechanisms include the Security.stripInaccessible() method, and Field and SObject describe methods.
---
# Apex Security and Sharing Model

The Apex security model includes record-level, field-level, and object-level security mechanisms. You can control record-level security modes by using the with sharing, without sharing, and inherited sharing keywords on classes. Apex runs in user mode by default, which means that user permissions on objects and field-level security are respected. A user cannot run code that tries to access fields or objects that are hidden from the user. Other security mechanisms include the Security.stripInaccessible() method, and Field and SObject describe methods.

## Versioned Behavior Changes

In API version 67.0 and later, you can’t use the WITH SECURITY\_ENFORCED clause in SOQL SELECT queries in Apex code. Instead, use the WITH USER\_MODE clause.

In API version 67.0 and later, Apex runs in user context by default, meaning that the current user’s permissions and field-level security (FLS) are enforced during code execution. In API version 66.0 and earlier, system mode is the default.

In API version 67.0 and later, classes without an explicit sharing declaration run in with sharing mode. In API version 66.0 and earlier, the sharing mode of classes without an explicit sharing declaration is determined according these factors.

- If the class is part of an inheritance chain, and any class in that chain is saved as API version 67.0 and later, the class runs in with sharing mode.
- If the class is an Aura controller or an @AuraEnabled method called from a Lightning web component, the class runs in with sharing mode.
- If the class isn’t an Apex entry point, its sharing mode is defined by the sharing mode of the calling class.
- Otherwise, the class runs in without sharing mode.

- **[Enforce Sharing Rules](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_security_sharing_rules.htm)**  
    In Apex, sharing rules are always enforced by default. Use the with sharing, without sharing, and inherited sharing keywords to control record-level security. If you don't want sharing rules to be enforced, then you must declare a class with the without sharing keyword.
- **[Enforce Object and Field Permissions](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_classes_perms_enforcing.htm)**  
    Apex generally runs in user context by default, meaning that the current user’s permissions and field-level security (FLS) are enforced during code execution. To ignore the FLS and object permissions of the current user, you must explicitly set a database operation or query to run in system mode. For fine-grained control, you can check the current user’s permissions for an object or a field, and then perform a specific DML operation or a query only if the user has sufficient permissions.
- **[Class Security](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_classes_security.htm)**  
    You can specify which users can execute methods in top-level classes or Apex transaction entry points based on their user profile or permission sets. You can only set security on Apex classes, not on triggers.
- **[Understanding Apex Managed Sharing](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_bulk_sharing.htm)**  
    Sharing is the act of granting a user or group of users permission to perform a set of actions on a record or set of records. Sharing access can be granted using the Salesforce user interface and Lightning Platform, or programmatically using Apex.
- **[Security Tips for Apex and Visualforce Development](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/pages_security_tips_intro.htm)**

#### See Also

- [Enforce Security with Field and SObject Describe Methods](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_classes_field_object_describe.htm "At the most granular level, you can enforce object-level and field-level permissions in your code by explicitly calling the Schema.DescribeSObjectResult and the Schema.DescribeFieldResult methods to check the current user’s access permission levels.")
- [_Apex Reference Guide_: stripInaccessible()](https://developer.salesforce.com/docs/atlas.en-us.264.0.apexref.meta/apexref/apex_class_System_Security.htm#apex_System_Security_methods)