Apex Security and Sharing in Salesforce

Author

mirketa

May 1, 2023

Salesforce provides a robust security model to protect data, ensuring that users have access only to the data they need. Apex, Salesforce’s proprietary programming language, follows this model to enforce security and sharing rules. Understanding Apex security best practices is crucial for developing secure and compliant applications.

Key Aspects of Apex Security

Enforcing User Permissions

Apex operates in system context, meaning it runs with elevated privileges by default. However, developers should enforce security checks to prevent unauthorized data access.

With Sharing vs. Without Sharing:
- with sharing ensures that record-level security is respected.
- without sharing runs Apex code with full system privileges.

Example:

public with sharing class AccountHandler { public List<Account> getUserAccounts() { return [SELECT Id, Name FROM Account]; } }

Field-Level and Object-Level Security

Even with sharing settings, users may not have permission to view certain fields or objects. Apex code must respect these permissions using:

Schema methods
Security.stripInaccessible() (introduced in API v45.0)

Example:

public List<Account> getAccessibleAccounts() {
    return [SELECT Id, Name FROM Account WHERE Schema.sObjectType.Account.isAccessible()];
}
public List<Account> getAccessibleAccounts() {
return [SELECT Id, Name FROM Account WHERE Schema.sObjectType.Account.isAccessible()];
}

Using stripInaccessible: SObjectAccessDecision decision = Security.stripInaccessible(AccessType.READABLE, [SELECT Id, Name FROM Account]); List<Account> accessibleAccounts = (List<Account>)decision.getRecords();

CRUD and FLS Enforcement

Apex does not automatically enforce CRUD (Create, Read, Update, Delete) and FLS (Field-Level Security). Always validate access before querying or modifying records.

if (Schema.sObjectType.Account.isUpdateable()) {
Account acc = [SELECT Id FROM Account LIMIT 1];
acc.Name = ‘Updated Name’;
update acc;
}

Apex Sharing Mechanisms

Record-Level Sharing

Record sharing in Salesforce is determined by:

Organization-Wide Defaults (OWD)
Role Hierarchies
Sharing Rules
Manual Sharing
Apex Sharing

Apex Managed Sharing

If declarative sharing is not sufficient, Apex Managed Sharing allows programmatic record access using the Share object.

Example:

AccountShare accShare = new AccountShare();
accShare.AccountId = ‘001XXXXXXXXXXXXXXX’;
accShare.UserOrGroupId = ‘005XXXXXXXXXXXXXXX’;
accShare.AccessLevel = ‘Read’;
insert accShare;

Using UserInfo for Context-Aware Access

Retrieve the current user’s ID:

Id currentUserId = UserInfo.getUserId();

Check profile or role:

String userProfile = [SELECT Profile.Name FROM User WHERE Id = :currentUserId].Profile.Name;

Best Practices for Apex Security

Always use with sharing unless explicitly required.
Utilize Security.stripInaccessible() to enforce FLS.
Check CRUD permissions before DML operations.
Avoid hardcoded IDs for sharing rules.
Regularly audit security settings using tools like Salesforce Health Check.

Conclusion

Security is a crucial aspect of Apex development in Salesforce. By enforcing user permissions, adhering to record-sharing rules, and following best practices, developers can build secure applications that align with Salesforce’s robust security framework.

Pranshu Goyal, Director of Products at Mirekta, states: “We envision DSM to be used by every small to a medium-sized organization dealing with bad data and want to get rid of duplicates easily with no cost. We have faced issues dealing with duplicates in our organization. That inspired us to make a solution that is not only simple to use but can be used widely to make the organization’s data clean to make them more efficient and productive. We want DSM to be a solution for every organization looking for duplicate management capability better than the Salesforce out-of-the-box solution with no additional cost.”