Secure | Salesforce Architects

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:

Ad hoc processes to activate or deactivate users
Unclear steps to update authorization for individual users when they change roles or system roles change
Relying on individuals with institutional knowledge for correct user security assignments

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:

Create Salesforce users based on individuals, not personas. Salesforce provides built-in auditing features that are most effective when there is a 1:1 mapping between Salesforce user accounts and entities accessing Salesforce with a user account. Shared user accounts decrease the usefulness of built-in auditing, create additional security risks, increase the potential damage stemming from account breaches, and hinder your ability to create effective authorization schemes. This includes user accounts for integration users.
Secure UI-based access scenarios. Most human users require some kind of UI-based access (often called login access) for a Salesforce org. Salesforce provides several layers of protection for these login scenarios, including:
- Password policies. Usernames and passwords are a primary target for cybercriminals seeking to gain unauthorized access to applications. Configuring password policies is a baseline step to protecting login access. This step alone is not sufficient, however, as password policies can be overridden on a per-user basis within Salesforce.
- Multi-factor authentication (MFA). Salesforce requires MFA for all UI-based user logins. In MFA scenarios, after successfully entering a username and password, users must also provide an additional type of identification, or factor, to verify their identity. This additional factor is usually in a physical format, like a mobile device, security key, or biometric marker. MFA is an essential defense against credential leaks and brute-force attacks.
- Single-sign on (SSO). In SSO scenarios, users only use one set of credentials across an organization’s applications. Access to systems is provisioned and managed from a central location, which improves security. Salesforce can act as a service provider or an identity provider in SSO scenarios. Be sure to allow some or all admins to log in directly to Salesforce so they can address outages or issues with your SSO implementation.
- Post-login steps. For some use cases, you might want your users to complete additional steps before they’re allowed to access your system. In such cases, you can use custom login flows to route users through an additional set of process steps before they are granted access to your system. Examples include:
  - Accepting terms and conditions
  - Working through login discovery and passwordless login scenarios
  - Limiting the number of simultaneous Salesforce sessions per user to reduce the likelihood of session-based attacks (see session security).
  - Connecting to geofencing services
Secure API-based access scenarios. Any user can request API-based access for a Salesforce org. Salesforce provides several layers of protection for API-based scenarios, including:
- API Access Control. Without API access control, anyone with a valid set of credentials can leverage any app to connect with your org — even if the connected app is not deployed in the org. Data access controls will still be enforced, but users could access information in uncontrolled ways. For example, someone could implement an app to download large volumes of data — or worse, upload a set of corrupted information — without a system administrator ever approving an app.
- API Only permissions. You can configure API Only user permissions in Salesforce. Assign this as part of a permission set to any automated or integration user personas to block UI-based access entirely.
- Certificates and keys. Certificates and keys enable Salesforce to validate that requests are actually coming from the business or company authorized to access a particular org. You will need to configure certificates and keys if you want to use SSO with Salesforce.
- Connected apps. Configuring connected apps in Salesforce enables you to control external system access to Salesforce, including required authentication protocols, authorization scope, and session behavior in a single definition.
- Named credentials. Named credentials enable you to control external access points and authentication protocols in a single definition within Salesforce. You can use them to securely define and manage authentication for callouts from Apex, external services, and Salesforce Connect data sources.

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:

Follow the principle of least privilege. The principle of least privilege (PoLP) is an approach to security in which users are assigned the minimal permissions necessary to carry out their work. To follow this principle, structure your permission sets to be granular and modular. This will enable you to create sophisticated access controls with permission set groups and to precisely manage permissions, which can be muted, set to expire, and more. Orient the functional units of your system to business capabilities to define granular permissions and effective permission set groups. Remember that permissions apply to metadata access in Salesforce. For details about configuring PoLP for Salesforce data access, see Sharing and Visibility.
Think about what users can access in terms of personas, not individuals. Thinking of authorization (or security in general) in terms of individual users will not set your system up to scale and evolve. A better approach is to design for and manage personas that represent groups of users. It’s important to recognize that Salesforce solutions architected to be secure use individuals for authentication, but personas for authorization. As you build your security model, specify the security configuration appropriate to each security persona. Determining access (and privileges) based on personas gives you the ability to control access at a granular level, and reduces the amount of refactoring involved in maintaining your system over time. Include the security personas you define in your design standards and documentation.
Use permission sets and permission set groups to control metadata access for users. Use permission sets and permission set groups to control what metadata users can access and what they can do with that metadata. (To learn more about Salesforce metadata, see Metadata versus Data) Configure app assignments, feature license activations, and managed package access as well as system permissions, CRUD access, and field-level access via permission sets and permission set groups. Include this access in your design design standards and documentation.
Use OWDs and sharing to control data access for users. Because data and metadata are distinct entities in Salesforce, access controls for data and metadata are also distinct. Use organization-wide defaults (OWDs) and built-in sharing tools to configure access for Salesforce data (individual records, files, and docs). For more details, see Data Security.
Use OAuth scopes to control access for connected apps. When you configure a connected app, you can determine what scope, or access permissions, users of the connected app should have to resources in Salesforce. For more about managing OAuth tokens, see Session Management.
Create one Salesforce user for every integration. To adhere to the principle of least privilege, create a separate Salesforce integration user for each integration, assigning them to a specific subset of data. This approach provides better control over operations, traceability of transactions, and minimizes the impact of any potential security breaches.
Minimize use of profiles and migrate any access controls out of profiles. Profiles provide the ability to limit access to login IP ranges, login hours, and specific features tied to the legacy Salesforce Classic user interface (specifically default record types and page layout assignments). Any functionality not directly tied to these features should be migrated to equivalent functionality in permission sets and permission set groups. Functionality in your profiles tied to Salesforce Classic UI features should be targeted for remediation.

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 shows a selection of patterns to look for (or build) in your org and anti-patterns to avoid or target for remediation.

✨ Discover more patterns for organizational security in the Pattern & Anti-Pattern Explorer.

	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 - If SSO is enabled, approved admin users have direct login access	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 - If SSO is enabled, no approved admin users have direct login access
	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, including: -- Modify All Data permissions -- View All Data permissions	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 - Permissions assigned to users follow security matrix definitions - Profiles are used minimally and only to control login IP ranges and login hours - A unique API only integration user is configured for every integration	In your org: - 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 - Permissions assigned to users do not follow security matrix definitions - Profiles contain access controls for metadata - API only users are not configured or are shared across more than one integration
	In Apex: - Database operations perform field- and object-level access checks appropriately, including: -- DML and Database DML statements declare user or system mode for data operations AND/OR -- DML and Database DML statements use `stripInaccessible` methods before data operations -- SOQL and SOSL statements use `WITH USER_MODE` and `WITH SYSTEM_MODE` keywords AND/OR -- `stripInaccessible` methods are used to filter query and subquery results -- sObject describe result methods (i.e. `isAccessible`, `isCreateable`, `isUpdateable`, and/or `isDeletable`) are used sparingly	In Apex: - DML, Database Class methods, SOQL and SOSL run in default system mode - Database operations do not perform access checks appropriately, including: -- DML or Database Class methods exclusively use `isAccessible`, `isCreateable`, `isUpdateable`, and/or `isDeletable` checks for sObject and field-level access -- SOQL queries exclusively use `WITH SECURITY_ENFORCED` keywords for access restrictions

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.

Sessions enable Salesforce to associate requests and responses with users. After a user is authenticated, the platform sends a session ID back to the client app. The client app includes this ID with any user requests (such as navigating, searching, and submitting data).
Tokens enable users and connected applications to verify their identity once and use a unique access token from then on. Tokens have a limited lifespan and only provide access to specific resources (see Authorization for more about configuring access levels). Tokens allow access to authorized resources without requiring users to login.

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:

Understand how Salesforce classifies session types. Identify and map approved session types to security user personas, and record these in your documentation.
Control how sessions can originate and where session traffic can go. Once you’ve identified the kinds of sessions various user personas are allowed to initiate, configure controls to block sessions that originate from unapproved sources or contexts. Salesforce provides several ways to control session origins and traffic, including:
- Built-in session protection. Salesforce automatically enables org-wide protections for session-based malicious activity, including cross-site scripting, cross-site request forgery, content sniffing, clickjacking and more. These protections should never be disabled (and some cannot be disabled).
- Domains and IP ranges. All Salesforce orgs have My Domain enabled by default, which creates a company-specific subdomain for Salesforce access. You can customize or change the name associated with an org through My Domain. Further, Salesforce supports additional domain configurations for Experience Cloud sites and other application pages. Note: If your users need to access Salesforce from behind a company firewall, add the required domains to your firewall allowlists. You can set up login IP ranges and trusted IP ranges to control inbound login and session requests to Salesforce.
- Login hours. If certain user personas have set working hours, you can restrict their ability to access Salesforce outside of defined login hours.
Control activities that require added session-level security. By default, sessions can have two kinds of security levels: standard and high-assurance. You can use these security levels to control how users can and cannot carry out activities such as accessing reports and dashboards, or managing the security configurations in a Salesforce org. Session-level security policies can require users to establish high-assurance sessions to carry out operations or block users from carrying out any sensitive operations at all.
Control activities that require added session-based permissions. Salesforce supports session-based permission activations to temporarily allow users elevated authorization or access to permissions during a particular session. You can activate and deactivate session-based permissions via Flow or Salesforce APIs.
Manage inactive user sessions through timeouts. Ending inactive sessions is a key part of managing session security. This helps protect your system when, for example, a user leaves a Salesforce session open in a browser tab but is actively working in another application, or when a user’s mobile device is logged into Salesforce, but the user isn’t near their mobile device. Salesforce has a default session inactivity timeout of two hours. You can increase or decrease session inactivity timeout levels. (Avoid increasing timeouts, however, without a compelling and well-documented reason.)
Manage connected app sessions through token configuration. When you configure a connected app, you also define the scope, or level of authorization, that will be granted to users accessing Salesforce through the connected app. This scope is enforced at the session level through OAuth tokens, which are issued after a user of a connected app successfully authenticates. You can control how long a token should last through token refresh policies. Org administrators can manually revoke tokens on a per-user and per-org basis, if needed.

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:

Use the mobile app solutions provided by Salesforce. Have users on mobile devices who need to access Salesforce use the official Salesforce apps available for iOS and Android. If business needs require a custom mobile solution, you should use the Salesforce Mobile SDK, which provides methods for secure authentication and authorization.
Design mobile device usage into your session management. Session security levels, session timeouts, and other session context controls should take into account any anticipated access from users on mobile devices. Consider what devices should and should not be allowed to access Salesforce, and what kinds of users should have access to mobile sessions. Include mobile access standards in your security persona documentation. For more on this topic, see Session Management.
Supplement device-level security with Mobile Device Management (MDM) technology. The Salesforce apps for iOS and Android are compatible with many popular MDM suites. You can configure additional access controls for the Salesforce app on user devices through your preferred MDM solution.
Supplement app-level security with Mobile Application Management (MAM) technology. MAM technology supports app-level controls on mobile devices. Salesforce offers a paid MAM add-on for Salesforce mobile apps.

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:

Use built-in audit capabilities. Salesforce offers a variety of built-in tools to help track and audit changes to your org. For example, you can view the audit history for administrative actions taken in an org through the Setup Audit Trail. Salesforce tracks field-level changes for a limited period of time by default — but you can activate Field History Tracking to display field changes for up to 18 months in the UI and up to 24 months via the API. Additionally, you can activate Field Audit Trail to retain an audit history for field-level changes indefinitely (until you manually delete the data).
Establish regular audit reviews. Auditing is a key part of detecting anomalous changes that may not be picked up as a real-time threat. Consider, for example, a user with legitimate access who deletes a small number of records every day for an extended period. Because this user has valid login credentials, has proper authorization to delete records, and is not deleting many records all at once, the activity isn’t likely to be detected as a threat in real time. For an audit team reviewing a report of user activities, however, the trend of a single user deleting an excessive number of records over time would be clearer to see and easier to respond to. As part of your governance policies, establish regular intervals for auditing login history, user session activity, and connected app usage.
Develop a threat response strategy and include it in your security policies. Create a threat response strategy that covers:
- Threat response type definitions (for example, alerts and automations) and any stakeholder groups that should be involved (For more on designing messages or alerts, see Errors and Notifications.)
- Specific categories for real-time changes or activities that could be considered threats and the associated response type for each
- A clear list of all automated threat responses (such as revoking tokens, ending sessions, deactivating user accounts, or blocking access to resources) and automation triggers

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 shows a selection of patterns to look for (or build) in your org and anti-patterns to avoid or target for remediation.

✨ Discover more patterns for session security in the Pattern & Anti-Pattern Explorer.

	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
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 the use of 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 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:

Design access around meaningful job functions. Create a security matrix that maps your user personas to business functions they are to perform. Use this template as a foundation to design your sharing and visibility. For more on identifying meaningful business functions, see Functional Units.
Choose the simplest path to applying the principle of least privilege As you apply the principle of least privilege in designing sharing and visibility schemes, do so in the most straightforward way. Avoid over-engineered data restrictions and sharing schemes, which can cause downstream issues for system maintainability, scalability, and adaptability. Instead, take advantage of the flexible, layered data sharing in Salesforce, which enables you to configure fine-grained rules for user access at the data level.
Set internal organization-wide defaults (OWDs) to Public Read Only, unless your business deals with sensitive data — then use Private. OWDs control the level of “least” privilege users will have at the data level. You cannot restrict access below the level of your OWD. For this reason, it may seem like choosing an OWD of Private is the optimal approach in every use case. However, in practice, users across the business can often end up inadvertently replicating a more permissive OWD through complex sharing schemes. Additionally, Private OWDs can cause users to create duplicate data. Sharing calculations (and re-calculations) may take a significant amount of time to complete depending on data volume and parent-child or ownership skew — Private OWDs exacerbate this. CRUD permissions and field-level visibility aren’t actually controlled by OWDs. Only choose an OWD of Private when it is justified by business needs — most often, such justifications will be related to compliance.
Set external organization-wide defaults (OWDs) to Private, unless you have a compelling business reason to allow greater access. External OWDs apply to users accessing Salesforce data from Experience Cloud sites, portals, and so on. Using External OWDs enables you to configure separate OWD baselines for internal and external users, to allow for differing types of “least” privilege. Always set the OWD for external users to Private — exceptions for a more open level must be clearly justified by business needs.

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.

Use of 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 use of encryption in your Salesforce solutions:

Always adequately encrypt data in transit. Salesforce employs Transport Layer Security (TLS) for all sessions that take place in a Salesforce-supported browser, and requires that outbound calls using HTTPS meet specific security standards. Platform APIs also employ HTTPS by default. Additionally, data sent between a Salesforce Experience Cloud site or a portal and its related Salesforce org is encrypted in transit by default. If you use Salesforce’s built-in email services, there are default levels for the Transport Layer Security (TLS) Salesforce uses to send and attempt delivery of email. You should, at a minimum, ensure the org settings are not lower than the default settings, unless you have clear business justification.
If the business requires it, encrypt data at rest. Salesforce offers different ways to encrypt data at rest.
- Hyperforce. Data is encrypted at rest in orgs that use Hyperforce. Encryption is managed for your org by Salesforce. You cannot create (or destroy) your own encryption keys.
- Salesforce Shield. Salesforce Shield enables you to encrypt data at rest in a Salesforce org. With Shield, you can create and destroy your own encryption keys. You can also encrypt unstructured data (including files, attachments, search indexes, and events).

The list of patterns and anti-patterns below shows what proper (and poor) use of 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 shows a selection of patterns to look for (or build) in your org and anti-patterns to avoid or target for remediation.

✨ Discover more patterns for data security in the Pattern & Anti-Pattern Explorer.

	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 - Generative AI operates only in user mode, or select uses for system access have clear business justification	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 - Generative AI operates in system mode 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
Use of 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

Tool	Description	Organizational Security	Session Security	Data Security
Apex Crypto Class	Encrypt and decrypt data in Apex			X
API Access Control	Manage access to your Salesforce APIs and connected apps	X	X	X
API Anomaly Event	Track anomalies in how users make API calls		X
Browser Security Settings	Protect sensitive data and monitor SSL certificates		X
Certificate-Based Authentication	Authenticate individuals with unique digital certificates	X	X
Certificates and Keys	Verify requests to external websites from Salesforce		X	X
Code Scanner	Scan Apex code for Security vulnerabilities		X	X
Connected Apps	Integrate via APIs and standard protocols	X	X
Credential Stuffing Event	Track attempted logins that use stolen user credentials		X
CSP Trusted Site	Prevent code injection attacks (i.e. cross-site scripting)		X
Custom Login Flows	Control login business processes for users	X
Customer Identity	Control website and app logins and verification	X
Data Mask	Automatically mask sensitive data in sandboxes			X
Debug Logs	Track events that occur in your org		X
Delegated Administration	Assign limited admin privileges to non-admin users	X		X
Device Activation	Verify logins from untrusted browsers, devices or IP ranges		X
Enhanced Transaction Security	Intercept events, monitor and control user activity		X
Field Access	Control data access at the field level			X
Field Audit Trail	Define a policy to retain archived field history data			X
Field History Tracking	Track and display field history			X
Frontdoor.jsp	Allow access with an existing session ID and server URL		X
Heroku Connect	Bi-directional synch between Heroku and Salesforce			X
Heroku Shield	Build HIPAA or PCI compliant apps			X
High Assurance Session Security	Require additional security for sensitive operations		X
Identity Connect	Map user records to Active Directory accounts	X
Identity Verification History	Audit user identity verification attempts	X
Integration User License	Grant access to data and features via API only.	X		X
Lightning Login	Prevent weak or forgotten passwords and locked-out accounts	X
Login Access	Allow support users to log in as another user	X
Login Forensics	Identify behavior that may indicate identity fraud		X
Login History	Monitor org and Experience Cloud site login attempts	X
Mobile Device Tracking	Track and monitor mobile device access to your org		X
Mobile SDK	Connect to the Salesforce Platform within stand-alone mobile apps	X	X	X
Monitor User Permissions (Shield)	Permission set and permission set group changes	X		X
Multifactor Authentication	Require two or more verification methods for login	X	X
Mutual Authentication	Enforce SSL or TLS mutual authentication
My Domain	Configure login pages and policies, SSO and social logins	X
Named Credentials	Specify endpoint URLs and authentication parameters		X
OAuth Authorization	Authorize client application access via token exchange	X
Password Policies	Set password history, length, and complexity	X
Permission Set Assignment Expirations	Set expirations for permission set and permission set group assignments	X		X
Permission Set Event	Monitor changes made to permission sets and permission set groups	X		X
Permission Set Groups	Bundle permission sets to support complex access requirements	X
Permission Sets	Control how users access metadata, features and apps	X
Private Connect	Secure integrations between Salesforce and Amazon Web Services			X
Profiles	Control login IP ranges and login hours	X
Real-Time Event Monitoring	Monitor and detect standard events in Salesforce		X
Remote Site Settings	Register external sites for Apex or JavaScript calls		X
Report Anomaly Event	Track anomalies in how users run or export reports		X
Restriction Rules	Prevent users from accessing unnecessary records			X
Salesforce Code Analyzer	Scan code via IDE, CLI or CI/CD to ensure it adheres to best practices		X	X
Scoping Rules	Control the default records your users can see			X
Security Center	View security and privacy settings across all your orgs			X
Security Health Check	Identify vulnerabilities in your security settings			X
Session Hijacking Event	Identify unauthorized access via stolen session identifiers		X
Session Management Class	Customize security settings for an active session		X
Session Security Settings	Configure sessions to protect against malicious attacks		X
Setup Audit Trail	Track recent setup changes made by admins			X
Sharing Settings	Control data access at the record level			X
Shield Platform Encryption	Encrypt sensitive data at rest and in transit			X
Single Sign-On	Provide access to multiple applications via a single login	X	X
System for Cross-Domain Identity Management (SCIM)	Manage identities across systems via REST APIs		X
Threat Detection	Use statistics and machine learning to detect threats		X
Trusted IP Ranges	Define IP addresses that don't require additional verification		X
User Access Report	Get a unified view of your users' object, record, and permissions access	X		X

Resources Relevant to Secure

Resource	Description	Organizational Security	Session Security	Data Security
A Guide to Sharing Architecture	Learn more about access tools, sharing models, and use cases			X
Design Standards Template	Create design standards for your organization	X	X	X
How to Build a User Security Model	Gain a better understanding of user security models	X		X
How to Implement the Principle of Least Privilege in Salesforce	Learn to apply PoLP data access controls in Salesforce	X		X
Monitor User Sessions	Review active sessions and end suspicious sessions		X
Multi-Factor Authentication	Access official MFA resources from Salesforce	X
Permission Set Groups (Trailhead)	Get hands-on with permission set groups	X		X
REST API Architecture	Understand REST API terms and concepts	X	X	X
Security and the SOAP API	Understand SOAP API terms and concepts	X	X	X
Security Best Practices for API and Internal System Users	Secure access to Salesforce by API users and secure internal system users	X
Security Implementation Guide	Take a comprehensive look at Salesforce Security	X	X	X
Security Policy Template	Set Security Policies for your Organization	X	X	X
Session Types	Identify the types of sessions used to access your org		X
Threat Modeling Fundamentals (Trailhead)	Learn about security threats and how to prevent them.		X

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.

Introduction

Organizational Security

Authentication

Authorization

Organizational Security Patterns and Anti-Patterns

Session Security

Session Management

Device Access

Threat Detection and Response

Session Security Patterns and Anti-Patterns

Data Security

Sharing and Visibility

Use of Encryption

Data Security Patterns and Anti-Patterns

Tools Relevant to Secure

Resources Relevant to Secure

Tell us what you think