Content last updated July 2022.
Read about our update schedules here.

Introduction

A secure system protects an organization’s stakeholders and data. Secure architectures help ensure that users accessing your system are who they say they are, allow access to only necessary data, and protect data within the system from being compromised.

Salesforce is committed to fostering and maintaining the trust of our customers — and the security of our platform is an essential part of that commitment. Maintaining the privacy and security of customer data is a cornerstone of the Salesforce Platform. You can explore real-time information about Salesforce system performance and security at Salesforce Trust.

Protecting your org and customer data is the foundation of building secure Salesforce solutions. As an architect building on Salesforce, you are responsible for deciding how to best use the built-in security features of Salesforce in your solutions, based on the specific requirements of your business. You’ll need to consider a variety of factors, including geographic distribution, industry, company operating procedures, and the type of customer data involved.

You can make your solutions more secure by focusing on three areas: organizational security, session security, and data security.

Organizational Security

Organizational security is about protecting your system against unauthorized access. Strong organizational security involves ensuring only validated, authorized users can access a system — and that validated users can only access necessary features and data.

Signs that you have problematic organizational security include:

You can build better organizational security controls for your Salesforce orgs by focusing on authentication and authorization.

Authentication

Authentication is a fundamental concept in security and access management. Authentication is the process of verifying the identity of a user who wants to access your system. This could be a human user, like an employee or customer, or an automated user like an external system or integration.

Different kinds of users require different authentication schemes. You will need to configure multiple kinds of authentication security to adequately validate user access across different entry points for your Salesforce org.

Consider the following to create secure authentication flows in Salesforce:

The list of patterns and anti-patterns below shows what proper (and poor) authentication architecture looks like in a Salesforce org. You can use these to validate your designs before you build, or identify opportunities for further improvements.

To learn more about authentication tools available from Salesforce, see Tools Relevant to Secure.

Authorization

Authorization is the process of determining the features, functionality, and data a user can access once they’ve been authenticated. It also involves determining what a user can do with the resources they can access.

Restricting who can authenticate into your org is a good first step. But if you don’t pair strong authentication with equally strong authorization, you haven’t actually secured your Salesforce org and your business. Without adequate authorization controls, a user in your system could create, edit, and delete records or access system functionality in ways that are harmful to your business and your stakeholders. Inadequate authorization control can also make systems harder to use. Controlling what users can do within the system creates higher levels of trust by protecting your system and your users.

Consider the following to build secure authorization schemes for Salesforce:

The list of patterns and anti-patterns below shows what proper (and poor) authorization looks like in a Salesforce org. You can use these to validate your designs before you build, or identify opportunities for further improvements.

To learn more about authorization tools available from Salesforce, see Tools Relevant to Secure.

Organizational Security Patterns and Anti-Patterns

The following table outlines patterns to look for (or build) in your org and anti-patterns to avoid or target for remediation.

Patterns Anti-Patterns
Authentication In your design standards and documentation:
- Approved security personas are clearly defined and listed
- Mapping between security personas and allowed authentication schemes (UI, API) exist in a security matrix
If design standards and documentation exist, they:
- Do not include security personas
- Do not include a security matrix with clear mappings for security personas and allowed authentication schemes
In your org:
- Login configurations align to the Salesforce MFA Check
- The relationship between users and entities logging into Salesforce is 1:1 (no shared users)
- API Access Control prevents users from authenticating via an unauthorized connected app
In your org:
- Login configurations do not align to the Salesforce MFA Check
- The relationship between users and entities logging into Salesforce is not 1:1 (there are shared user accounts)
- If users access Salesforce from behind a firewall, the firewall uses hard-coded IP addresses to secure communications to/from Salesforce
- API Access Control is not enabled
In LWC, Apex, Aura:
- Methods that execute authentication use named credentials to handle username/password flows
- No usernames or passwords appear in code in readable formats (no hard-coded values or strings)
- If custom login flows exist, all related custom code uses appropriate SessionManagement methods
In LWC, Apex, Aura:
- Authentication is handled ad hoc
- Usernames and passwords appear in code
Authorization In your design standards and documentation:
- Every user and system with access to Salesforce maps to one or more personas in a security matrix
- The security matrix clearly lists metadata permissions and assigned user personas
- Use cases for granting elevated privileges are clearly listed
If design standards and documentation exist, they:
- Do not include a security matrix
- Do not clearly list permissions
- Do not clearly list use cases for granting elevated privileges
In your org:
- Permission sets and permission set groups are used to control access to metadata
- Permission sets and permission set groups align to business capabilities
- Profiles are used minimally and only to control login IP ranges and login hours
In your org:
- Profiles contain access controls for metadata
- Permission set groups are not configured to allow for access based on business capabilities
- Permission sets are configured ad hoc
- Permission sets are redundant or are heavily duplicated; it is difficult to understand clear functional logic and differences between sets
In Apex:
- All DML or Database Class methods employ isAccessible, isCreateable, isUpdateable, and/or isDeletable checks for both sObject and field
-level access before carrying out operations
- All SOQL queries include WITH SECURITY_ENFORCED keywords to enforce object and field-level access
In Apex:
- DML and/or Database Class methods run in default system mode, without checking for user permission
- SOQL queries do not include WITH SECURITY_ENFORCED keywords and run in default system mode

Session Security

A session is the series of requests and responses associated with a user over a period of time. A session is initiated when a user successfully authenticates into Salesforce. Session security is the practice of configuring your system in a way that prevents unauthorized parties from accessing your system or data by interfering with or hijacking sessions.

Since all user activity in your system takes place in the context of a session, it is critical to account for the ways sessions can begin, what can take place during a session, and what devices users will be (and should be) using, as well as how to see and respond to suspicious or anomalous session behaviors.

You can build session security in Salesforce by focusing on three keys: session management, device access, and threat detection and response.

Session Management

Sessions, which are initiated when a user successfully authenticates and gains access to Salesforce, enable the platform to associate specific requests and responses with a particular user.

HTTPS is the protocol that enables communication between a front-end client and a server. In this context, the server is the Salesforce Platform. Clients can include browsers, mobile applications, local applications, and so on. HTTPS is a stateless protocol, which means that every communication is discrete and unrelated to any previous or future communications.

This stateless approach helps to speed up network communications and eliminates errors caused by broken links between packets. However, web apps still need a way to keep track of each user’s identity and other related information across multiple request and response interactions. Like most other web applications, Salesforce uses sessions and tokens to address this.

If sessions and tokens aren’t secured properly, bad actors can potentially interfere with them and impersonate users or execute malicious code in your system.

Consider the following to build secure session management for Salesforce:

The list of patterns and anti-patterns below shows what proper (and poor) session management looks like in a Salesforce org. You can use these to validate your designs before you build, or identify opportunities for further improvements.

To learn more about session management tools available from Salesforce, see Tools Relevant to Secure.

Device Access

In the current context, a device is any piece of electronic equipment that an individual will use to access Salesforce, such as a desktop workstation, laptop, tablet, or mobile phone.

While the ability to access Salesforce from portable devices gives users the flexibility to work from anywhere, it can also create additional attack vectors for bad actors. These vectors range from simple (looking over someone’s shoulder in a coffee shop and stealing their credentials) to advanced (installing malware on a device or creating a phony public Wi-Fi network to monitor data transmissions). Because of this, securing devices — especially portable devices — is essential to overall system security.

Consider the following to secure device access for Salesforce:

The list of patterns and anti-patterns below shows what proper (and poor) device management looks like in a Salesforce org. You can use these to validate your designs before you build, or identify opportunities for further improvements.

To learn more about device management tools available from Salesforce, see Tools Relevant to Secure.

Threat Detection and Response

Threat detection is the process of identifying behavior patterns in your system that may indicate malicious activity. This can include larger than average volumes of data being downloaded or a user modifying fields containing sensitive data on several records within a shorter than average period of time. Responses to threats can include automated session expiration, alerting, and other notifications.

The goal of threat detection is to identify and respond to potential issues as quickly as possible. Taking action based on real-time threat detection can stop malicious behavior in its tracks. Salesforce offers real-time event monitoring as an add-on or as part of Salesforce Shield. Use one of these solutions if you have highly sensitive applications or require robust real-time threat detection and response capabilities.

Consider the following to build an effective threat detection and response strategy for your Salesforce solutions:

The list of patterns and anti-patterns below shows what proper (and poor) threat detection and response looks like in a Salesforce org. You can use these to validate your designs before you build, or identify opportunities for further improvements.

To learn more about threat detection, alerting, and response automation tools available from Salesforce, see Tools Relevant to Secure.

Session Security Patterns and Anti-Patterns

The following table outlines patterns to look for (or build) in your org and anti-patterns to avoid or target for remediation.

Patterns Anti-Patterns
Session Management In your design standards and documentation:
- Security personas clearly list approved session types and timeout/duration settings for each persona
- Login hours have been specified (or identified as not needed)
- Operations requiring elevated session-level security or permissions are clear and discoverable
- Connected app scope and token management policies are clear and discoverable
In your design standards and documentation:
- Security personas do not exist or lack information about session types and timeout/duration settings
- Security policies do not contain information about connected app scopes or token management
In your org:
- Session audits show users only access Salesforce through expected session types
- There is a clear, active permission set for "API Only User" access (with "API Only" permission set to TRUE) and all integration and automated users are assigned
- If users access Salesforce from behind a firewall, the firewall uses an allowlist of required domains instead of IP addresses to secure communications to/from Salesforce
- Inactive session timeout intervals do not exceed the default (2 hours)
- All of the following settings are enabled:
-- Clickjack protection for Setup pages
-- Clickjack protection for non-Setup Salesforce pages
-- Cross-Site Request Forgery (CSRF) protection
-- Cross-Site Scripting (XSS) protection
-- Enable content sniffing protection
-- Referrer URL protection
-- Warn users before they are redirected outside of Salesforce
In your org:
- There is no regular session auditing
- There are no definitions of what session types users should have
- “API Only" permissions are unclear or missing from integration and automated users
- If users access Salesforce from behind a firewall, the firewall uses hard-coded IP addresses to secure communications to/from Salesforce
- Inactive session timeout intervals exceed the default (2 hours)
- Any of the following settings are disabled:
-- Clickjack protection for Setup pages
-- Clickjack protection for non-Setup Salesforce pages
-- Cross-Site Request Forgery (CSRF) protection
-- Cross-Site Scripting (XSS) protection
-- Enable content sniffing protection
-- Referrer URL protection
-- Warn users before they are redirected outside of Salesforce
In LWC, Apex, Aura:
- If custom login flows exist, all related custom code uses appropriate SessionManagement methods to assign session-level security
In LWC, Apex, Aura:
- If custom login flows exist, there is no logic to assign session-level security
Device Access In your design standards and documentation:
- Device policies are clear and discoverable
- Security personas are clearly mapped to appropriate device usages and policies
In your design standards and documentation:
- Security policies do not exist or do not contain information about device access
In your org:
- Salesforce mobile connected app configuration requires PIN/passcode unlock after inactivity
- If business needs require strict control of users who can access Salesforce mobile, API Access Control is enabled and permission sets are assigned to all users of Salesforce mobile apps
In your org:
- Salesforce mobile connected app is not configured to require PIN/passcode unlock for inactivity
– Business needs require strict control of users who can access Salesforce mobile, but API Access Control is not enabled or permission sets are not used to control access to Salesforce mobile apps
Threat Detection and Response In your design standards and documentation:
- Security policies contain a list of events that should trigger a response along with the appropriate response type
- Audit levels have been specified for all objects in your data model
- Steps to review logs available within Salesforce are documented
- All automated responses are documented clearly
In your design standards and documentation:
- Security policies do not exist or do not include information about threat detection and alerting
- Documentation for automated responses does not exist or is unclear
Within your company:
- Audit data is available in reports business stakeholders can understand and access
- Regular reviews of audit history and reports take place
Within your company:
- Audit data is only available through log files that require subject matter expertise to access and interpret
- No processes exist to review auditing information
In your org:
- Automations are in place to respond to threats by deactivating user accounts or blocking access to resources in real time if abnormal usage is detected
- Notifications and alerts are configured to notify appropriate users about anomalous activity
- Field History tracking is enabled for all fields containing private or sensitive data
In your org:
- There are no automations in place to respond to threats
- Notifications and alerts are either not configured to notify appropriate users about anomalous activity, or some notifications and alerts related to anomalous activity exist, but they are ad hoc
- Field History tracking is not consistently enabled for fields containing private or sensitive data

Data Security

Data security is the practice of protecting your data from unauthorized access, corruption, or unintended deletion. Data security involves safeguarding data both in transit and at rest.

Strong data security minimizes the risks and potential damages from unauthorized access to your system. Systems without adequate data security are more at risk of data breaches, which can cause great harm to your customers and your company. Protecting your data is an essential part of building secure architectures.

Improving data security starts with a clear understanding of what is considered data within Salesforce. The individual records, files, and documents stored within a Salesforce org are its data. (For more on the distinction between metadata and data, see Salesforce Architecture Basics.)

You can build stronger data security in your Salesforce solutions by focusing on sharing and visibility as well as encryption.

Note: When designing for data security, be sure to take into account data privacy as well as archiving and purging, as both of these concepts will affect the overall data security of your solutions.

Sharing and Visibility

Sharing and visibility involves configuring your system to control how users access data within Salesforce. It is important to note that sharing and visibility control which individual records a user can access — but sharing and visibility alone does not ultimately control what a user can do with a particular record, nor which fields are visible to a user when they access a record. Permissions to carry out data operations (like CRUD) are assigned to users through metadata access controls, which can be configured for a user at the individual object and field level. For more on this, see Authorization.

Consider the following to configure effective sharing and visibility in Salesforce:

The list of patterns and anti-patterns below shows what proper (and poor) sharing and visibility looks like in a Salesforce org. You can use these to validate your designs before you build, or identify opportunities for further improvements.

To learn more about sharing and visibility tools from Salesforce, see Tools Relevant to Secure.

Encryption

Encryption focuses on ways to convert data from a format that is easily read or understood into an encoded format that is indecipherable. Encrypted data can be decrypted, or translated back to its original form, via a key. Encryption is among the most effective methods for securing data at rest and in transit because it ensures that in the event data is accessed by an unauthorized party, it will be unreadable.

Consider the following to design for proper encryption in your Salesforce solutions:

The list of patterns and anti-patterns below shows what proper (and poor) data encryption looks like in a Salesforce org. You can use these to validate your designs before you build, or identify opportunities for further improvements.

To learn more about encryption tools available from Salesforce, see Tools Relevant to Secure.

Data Security Patterns and Anti-Patterns

The following table outlines patterns to look for (or build) in your org and anti-patterns to avoid or target for remediation.

Patterns Anti-Patterns
Sharing and Visibility In your design standards and documentation:
- A security matrix outlines the data each user persona is authorized to access
- Different data access standards are used for external users and internal users, if applicable
In your design standards and documentation:
- Design standards and documentation do not exist or do not contain a security matrix
- If a security matrix exists, it does not outline data access for user personas
In your org:
- Organization-wide defaults (OWDs) for internal users is Public Read, or OWDs for internal users is Private, due to compliance requirements
- OWDs for external users is Private
In your org:
- OWDs for internal users is set to Private without business justification or OWDs for internal users is set to Public Read/Write
- OWDs for external users are set to anything other than Private without business justification
In Apex:
- All code accessing data (SOQL/SOSL) or performing data operations (DML/Database Class methods) uses with sharing keywords
In Apex:
- with sharing keywords are used inconsistently
Encryption In your design standards and documentation:
- Use cases for data encryption in transit and (if needed) at rest are clear and discoverable
- Approved encryption protocols are clearly listed
- Code documentation clearly indicates where encryption is used and what protocols are used
In your design standards and documentation:
- Approved encryption protocols are not clear or not listed
- Code is not documented or documentation is unclear on where and how encryption is used in code
In your org:
- If security risks are identified that require greater data protection at rest, either Hyperforce or Salesforce Shield provide encryption at rest
In your org:
- Business needs require greater data protection at rest, but neither Hyperforce nor Salesforce Shield is used
In Apex:
- If business needs require greater data protection in transit, all code involved in integration carries out logic using Crypto Class methods to encrypt data before transmission or decrypt data upon receipt
In Apex:
- Business needs require greater data protection in transit, but code involved in integration carries out logic without encrypting data before transmission or upon receipt, or Crypto Class methods are used ad hoc

Tools Relevant to Secure

ToolDescriptionOrganizational SecuritySession SecurityData Security
Apex Crypto ClassEncrypt and decrypt data in ApexX
API Access ControlManage access to your Salesforce APIs and connected appsX XX
API Anomaly EventTrack anomalies in how users make API callsX
Browser Security SettingsProtect sensitive data and monitor SSL certificatesX
Certificate-Based AuthenticationAuthentate individuals with unique digital certificatesXX
Certificates and KeysVerify requests to external websites from SalesforceXX
Connected AppsIntegrate via APIs and standard protocolsXX
Credential Stuffing EventTrack attempted logins that use stolen user credentialsX
CSP Trusted SitePrevent code injection attacks (i.e. cross-site scripting)X
Custom Login FlowsControl login business processes for usersX
Customer IdentityControl website and app logins and verificationX
Data MaskAutomatically mask sensitive data in sandboxesX
Debug LogsTrack events that occur in your orgX
Delegated AdministrationAssign limited admin privileges to non-admin usersXX
Device ActivationVerify logins from untrusted browsers, devices or IP rangesX
Enhanced Transaction SecurityIntercept events, monitor and control user activityX
Field AccessControl data access at the field levelX
Field Audit TrailDefine a policy to retain archived field history dataX
Field History TrackingTrack and display field historyX
Frontdoor.jspAllow access with an existing session ID and server URLX
Heroku ConnectBi-directional synch between Heroku and SalesforceX
Heroku ShieldBuild HIPAA or PCI compliant appsX
High Assurance Session SecurityRequire additional security for sensitive operationsX
Identity ConnectMap user records to Active Directory accountsX
Identity Verification HistoryAudit user identity verification attemptsX
Lightning LoginPrevent weak or forgotten passwords and locked-out accountsX
Login AccessAllow support users to log in as another userX
Login ForensicsIdentify behavior that may indicate identity fraudX
Login HistoryMonitor org and Experience Cloud site login attemptsX
Mobile Device TrackingTrack and monitor mobile device access to your orgX
Mobile SDKConnect to the Salesforce Platform within stand-alone mobile appsXXX
Monitor User Permissions (Shield)Permission set and permission set group changesXX
Multifactor AuthenticationRequire two or more verification methods for loginXX
Mutual AuthenticationEnforce SSL or TLS mutual authentication
My DomainConfigure login pages and policies, SSO and social loginsX
Named CredentialsSpecify endpoint URLs and authentication parametersX
OAuth AuthorizationAuthorize client application access via token exchange X
Password PoliciesSet password history, length, and complexityX
Permission Set Assignment ExpirationsSet expirations for permission set and permission set group assignmentsXX
Permission Set EventMonitor changes made to permission sets and permission set groupsXX
Permission Set GroupsBundle permission sets to support complex access requirementsX
Permission SetsControl how users access metadata, features and appsX
Private ConnectSecure integrations between Salesforce and Amazon Web ServicesX
ProfilesControl login IP ranges and login hoursX
Real-Time Event MonitoringMonitor and detect standard events in Salesforce X
Remote Site SettingsRegister external sites for Apex or JavaScript callsX
Report Anomaly EventTrack anomalies in how users run or export reportsX
Restriction RulesPrevent users from accessing unnecessary recordsX
Scoping RulesControl the default records your users can seeX
Security CenterView security and privacy settings across all your orgsX
Security Health CheckIdentify vulnerabilities in your security settingsX
Session Hijacking EventIdentify unauthorized access via stolen session identifiersX
Session Management ClassCustomize security settings for an active sessionX
Session Security SettingsConfigure sessions to protect against malicious attacksX
Setup Audit TrailTrack recent setup changes made by adminsX
Sharing SettingsControl data access at the record levelX
Shield Platform EncryptionEncrypt sensitive data at rest and in transitX
Single Sign-OnProvide access to multiple applications via a single loginXX
System for Cross-Domain Identity Management (SCIM)Manage identities across systems via REST APIsX
Threat DetectionUse statistics and machine learning to detect threatsX
Trusted IP RangesDefine IP addresses that don't require additional verificationX

Resources Relevant to Secure

ResourceDescriptionOrganizational SecuritySession SecurityData Security
A Guide to Sharing ArchitectureLearn more about access tools, sharing models, and use casesX
Design Standards TemplateCreate design standards for your organizationXXX
How to Build a User Security ModelGain a better understanding of user security modelsXX
How to Implement the Principle of Least Privilege in SalesforceLearn to apply PoLP data access controls in SalesforceXX
Monitor User SessionsReview active sessions and end suspicious sessionsX
Multi-Factor AuthenticationAccess official MFA resources from SalesforceX
Permission Set Groups (Trailhead)Get hands-on with permission set groupsXX
REST API ArchitectureUnderstand REST API terms and conceptsXXX
Security and the SOAP APIUnderstand SOAP API terms and conceptsXXX
Security Best Practices for API and Internal System UsersSecure access to Salesforce by API users and secure internal system usersX
Security Implementation GuideTake a comprehensive look at Salesforce SecurityXXX
Security Policy TemplateSet Security Policies for your OrganizationXXX
Session TypesIdentify the types of sessions used to access your orgX

Tell us what you think

Help us keep Salesforce Well-Architected relevant to you; take our survey to provide feedback on this content and tell us what you’d like to see next.