| Timeout value |
Length of time after which the system logs out inactive users. For portal
users, the timeout is between 10 minutes and 24 hours, even though you can only
set it as low as 15 minutes. Select a value between 15 minutes and 24 hours.
Choose a shorter timeout period if your Salesforce org has sensitive information
and you want to enforce stricter security.The last active session time value
isn’t updated until halfway through the timeout period. So if you have a
30-minute timeout, the system checks for activity when 15 minutes have passed.
If you update a record after 20 minutes, your timeout resets because it’s
5 minutes after the active session time is checked. In that scenario, you have
another 30 minutes before logout occurs, for a total of 50 minutes. But if you
update a record after 10 minutes, logout occurs 20 minutes later (30 minutes
total) because there was no activity in the past 15 minutes. |
| Disable session timeout warning popup |
Determines whether the system prompts inactive users with a timeout warning
message. Users are prompted 30 seconds before timeout, as specified by the timeout
value. |
| Force logout on session timeout |
Requires that when sessions time out for inactive
users, current sessions become invalid. The browser refreshes and returns to the
login page. To access the org, the user must log in again.When using
this setting, avoid selecting Disable session timeout warning
popup. |
| Lock sessions to the IP address from
which they originated |
Determines whether user sessions are locked to the IP address from which the
user logged in, helping to prevent unauthorized persons from hijacking a valid
session.This setting can inhibit various applications and mobile
devices. |
| Lock sessions to the domain in which they
were first used |
Associates a current UI session for a
user, such as an Experience Cloud site user, with a specific domain. The setting
helps prevent unauthorized use of the session ID in another domain. This setting
is enabled by default for orgs created with the Spring ’15 release or
later. |
| Require secure connections
(HTTPS) |
Determines whether HTTPS is required to log in to or access
Salesforce. This setting is enabled by default for security reasons. This
setting doesn't apply to API requests. All API requests require HTTPS.
To
enable HTTPS on Experience Cloud sites and Salesforce Sites, see HSTS for Salesforce Sites and Experience Cloud
Sites.
- The Reset Passwords for Your Users page can only be accessed using HTTPS.
- If this setting is disabled, Salesforce won't be
fully functional for Google Chrome users after the Chrome 80 release in
February 2020. The default SameSite behavior for cookies in Chrome
requires HTTPS in Salesforce.
|
| Require secure connections (HTTPS) for all third-party domains |
Determines whether HTTPS is required for connecting to third-party
domains. This setting is enabled by default on accounts created after the
Summer ’17 release.
If this setting is disabled, Salesforce won't be
fully functional for Google Chrome users after the Chrome 80 release in
February 2020. The default SameSite behavior for cookies in Chrome
requires HTTPS in Salesforce. |
| Force relogin after Login-As-User |
Determines whether an admin who is logged in as another user is returned to
their previous session after logging out as the secondary user. If the setting is enabled, an admin must log in
again to continue using Salesforce after logging out as the user. Otherwise,
the admin is returned to the original session after logging out as the
user. This setting is enabled by default for all orgs.
|
| Require HttpOnly attribute |
Restricts session ID cookie access. A cookie with the HttpOnly attribute
isn't accessible via non-HTTP methods, such as calls from JavaScript.If you have a custom or packaged application that uses
JavaScript to access session ID cookies, selecting Require HttpOnly attribute
breaks your application. It denies the application access to the cookie. If
Require HttpOnly attribute is selected, the AJAX Toolkit debugging window
isn’t available. |
| Use POST requests for cross-domain sessions |
Sets the org to send session information using a POST request, instead of a
GET request, for cross-domain exchanges. An example of a cross-domain exchange is
when using a Visualforce page. In this context, POST requests are more secure than
GET requests because POST requests keep the session information in the body of the
request. However, if you enable this setting, sometimes embedded content, such as
an image, from another domain doesn’t display. |
| Enforce login IP ranges on every request |
Restricts the IP addresses from which users can access Salesforce to only the
IP addresses defined in Login IP Ranges. If this setting is enabled, login IP
ranges are enforced on each page request, including requests from client
applications. If this setting isn’t enabled, login IP ranges are enforced only
when a user logs in. This setting affects all user profiles that have login IP
restrictions. |
|
Login IP Ranges (for Contact Manager,
Group, and Professional Editions) |
Specifies a range of IP addresses users must log in from (inclusive), or the
login fails. To specify a range, click New and enter a
Start IP Address and End IP Address to define the range, which includes the
start and end values.
This field isn't available in Enterprise, Unlimited,
Performance, and Developer Editions. In those editions, you can specify a valid
Login IP Range in the user profile settings.
|
| Enable caching and autocomplete on login page |
Allows the user’s browser to store usernames. If enabled, after
initial login, usernames are auto-filled into the Username field on the login
page. If the user selected Remember me on the login page,
the username persists after the session expires or the user logs out. The username
also appears on the Switcher. This setting is selected by default for all orgs.
To improve your org’s security posture, we recommend that you disable this
setting. After you disable it, the Remember me option doesn’t appear on your
org’s login page or from the Switcher. |
| Enable secure and persistent browser caching to improve performance |
Enables secure data caching in the browser to improve page reload performance
by avoiding extra round trips to the server. This setting is selected by
default.Disabling secure and
persistent browser caching has a significant negative performance impact on
Lightning Experience. Only disable in the following scenarios:
- Your company’s policy doesn’t allow browser caching, even if the data is
encrypted.
- During development in a sandbox or Developer Edition org to see the effect
of any code changes without needing to empty the secure cache.
|
| Enable user switching |
Determines whether the Switcher appears when your users select their profile
picture. This setting is selected by default. The Enable caching and autocomplete
on login page setting must also be enabled. Deselect the Enable user switching
setting to prevent your org from appearing in Switchers on other orgs. It also
prevents your org users from seeing the Switcher when they select their profile
picture. |
| Remember until logout |
Normally, usernames are cached only while a session is active or if a user
selects Remember Me. The remember option isn't available
for SSO sessions. When the session expires, the username disappears from the
login page and the Switcher. By enabling Remember me until logout, the cached
usernames are deleted only if the user explicitly logs out. If the session times
out, they appear on the Switcher as inactive. This way, if the users are on
their own computer and allow a session to time out, they can select the username
to reauthenticate. If they're on a shared computer, the username is deleted
immediately when the user logs out.
This setting applies to all your org’s users. This option isn't enabled by
default. However, we encourage you to enable it as a convenience to your users.
Keep this setting disabled if your org doesn't expose all your SSO or
authentication providers on your login page.
|
| Enable Content Delivery Network (CDN) for Lightning Component
framework |
Allows users to load Lightning Experience and other
apps faster by enabling Akamai’s content delivery network (CDN) to serve the
static content for Lightning Component framework. A CDN generally speeds up page
load time, but it also changes the source domain that serves the files. If your
company has IP range restrictions for content served from Salesforce, test
thoroughly before enabling this setting. CDNs
improve the load time of static content by storing cached versions in multiple
geographic locations. This setting turns on CDN delivery for the static
JavaScript and CSS in the Lightning Component framework. It doesn’t distribute
your org’s data or metadata in a CDN.
|
| Let users verify their identity by text (SMS) |
Allows users to receive an identity verification code in
a text message. Users must verify their phone number before they can receive
identity verification codes by text. This setting is enabled by default for all
orgs. A verification code is valid for 24 hours. If the code isn’t used during
that time, you can generate a new verification code by reinitializing initSelfRegistration. To disable SMS as a
method of verification, contact Salesforce support. The email method of identity
verification can't be disabled.
|
| Prevent identity verification by email when other methods
are registered |
Allows users to get verification codes by email only
if no other identity method has been verified. Other verification methods include
Salesforce Authenticator, SMS, time-based one-time password (TOTP), and physical
key (U2F). This setting is enabled by default for all orgs. A verification code is
valid for 24 hours. If the code isn’t used during that time, you can generate a
new verification code by reinitializing initSelfRegistration. |
| Require security tokens for API logins from
callouts (API version 31.0 and earlier) |
Requires the use of security tokens for
API logins from callouts in API version 31.0 and earlier. Examples are Apex
callouts or callouts using the AJAX proxy. In API version 32.0 and later, security
tokens are required by default. |
| Let users verify their identity with a physical
security key (U2F) |
Permits the use of a U2F security key for
multi-factor authentication (MFA) and identity verification. Instead of using
Salesforce Authenticator, one-time passwords generated by an authenticator app, or
one-time passwords sent by email or SMS, users insert their registered U2F
security key into the appropriate port to complete verification. |
| Let users authenticate with a certificate |
Enables certificate-based authentication to use
PEM-encoded X.509 digital certificates to authenticate individual users to your
org. |
| Require identity verification during
multi-factor authentication (MFA) registration |
Requires users to confirm their
identities before adding an MFA verification method, such as Salesforce
Authenticator, instead of requiring a relogin as before. |
| Require identity verification for email
changes |
Requires users to log in again and confirm their identity before their email
address change takes effect. Users verify their identity using a registered
verification method, such as Salesforce Authenticator, SMS, or email.
If the user’s verification method is email, the verification code is sent to
the user’s previously registered email address rather than the new email
address. |
| Require email confirmations for email address
changes (applies to external users in Experience Builder sites) |
Requires Experience Cloud site users to confirm
that they own the new email address. When users change their own email address,
they receive an email at both their old and new email addresses with a link. After
they click the link, their new email address takes effect. If an admin changes a
site user's email address, the site user doesn't receive an email confirmation.
Email confirmations are enabled by default for orgs created in Winter ’20 and
later. For orgs created before Winter ’20, Salesforce recommends that you enable
this option as a security precaution. This option doesn’t apply to
employees.By default, site users also receive an email confirmation when
they change their own username. If an admin changes the username of a site user,
the site user doesn't receive an email confirmation. This feature allows admins
to change usernames for site users without notifying them. However, if an admin
changes an employee's username, the employee receives an email confirmation.
|
| Let Salesforce Authenticator automatically
verify identities using geolocation |
Allows Salesforce Authenticator to use
the phone's location services to verify a user's identity. If users approve the
location, they aren't prompted for their identity when at that location. If the
location isn't approved, or if users are outside the trusted location, they're
prompted to verify their identity. |
| Let Salesforce Authenticator automatically
verify identities based on trusted IP addresses only |
Allows Salesforce Authenticator to use
trusted IP ranges to verify a user’s identity. When users are located within
trusted IP address ranges, they aren't prompted to verify their identity. If users
are outside the trusted IP address range, they're prompted to verify their
identity. |
| Prevent login from mobile user devices with revoked
status |
Prevents a user with a revoked UserDevice from
logging in from a Salesforce app. Logins from browsers aren’t affected. |
| Allow Lightning Login |
Permits the use of Lightning Login to log in to Salesforce with Salesforce
Authenticator instead of a password. |
| Allow only for users with the Lightning Login User permission |
Allows users to use Lightning Login to log in to Salesforce with Salesforce
Authenticator instead of a password when the Lightning Login user permission is
enabled. |
| Enable clickjack protection for Setup pages |
Protects against clickjack attacks on setup Salesforce pages. Clickjacking is also known as a user
interface redress attack. (Setup pages are available from the Setup
menu.) |
| Enable clickjack protection for non-Setup Salesforce pages |
Protects against clickjack attacks on non-setup Salesforce pages. Clickjacking is also known as a user
interface redress attack. Setup pages
already include protection against clickjack attacks. (Setup pages are available
from the Setup menu.) This setting is selected by default for all orgs. |
| Enable clickjack protection for customer Visualforce pages with standard
headers |
Protects against clickjack attacks on your Visualforce pages with headers
enabled. Clickjacking is also known as a user
interface redress attack. Also
allows iframes on trusted external domains. To enable this feature, add external
domains where you allow framing under Trusted Domains for Inline
Frames.
|
| Enable clickjack protection for customer Visualforce pages with headers
disabled |
Protects against clickjack attacks on your Visualforce pages with headers
disabled when setting showHeader="false"
on the page. Clickjacking is also known as a user
interface redress attack. Also allows iframes on trusted external domains. To enable this feature,
add external domains where you allow framing under Trusted Domains for Inline
Frames.
|
| Enable CSRF protection on GET requests on non-setup pages |
Protects against Cross Site Request Forgery
(CSRF) attacks by modifying non-Setup pages. Non-Setup pages include a random
string of characters in the URL parameters or as a hidden form field. With every
GET and POST request, the application checks the validity of this string of
characters. The application doesn't execute the command unless the value found
matches the expected value. This setting is selected by default. |
| Enable CSRF protection on POST requests on non-setup pages |
| Enable Stricter Content Security Policy |
The Lightning Component framework uses Content Security Policy (CSP), the W3C
standard to control the source of content that can be loaded on a page. The Enable
Stricter Content Security Policy setting was introduced in the Winter ‘19 release
to prohibit the use of the unsafe-inline
source for the script-src directive. The
setting mitigates the risk of cross-site scripting attacks and was enabled by
default. In the current release, this setting is always enabled and unsafe-inline is always prohibited, even if this
setting appears to be disabled. We plan to remove the setting from Session
Settings in a future release, as the restriction on unsafe inline JavaScript is
always enforced. |
| Lightning Locker API Version |
Sets the API version for Lightning Locker compatibility for all Lightning
components that don't specify an API version. Lightning Locker enhances security
with each version, so we recommend updating your custom components to comply
with the latest. If you’re unable to update them right away, or require a
managed package that’s incompatible with the latest, you can temporarily select
an earlier, compatible API version.
|
| XSS protection |
Protects against reflected cross-site scripting attacks. If a reflected
cross-site scripting attack is detected, the browser shows a blank page with no
content. |
| Content Sniffing protection |
Prevents the browser from inferring the MIME type from the document content.
It also prevents the browser from executing malicious files (JavaScript,
Stylesheet) as dynamic content. |
| Referrer URL Protection |
When loading pages, the referrer header shows only Salesforce.com rather than
the entire URL. This feature eliminates the potential for a referrer header to
reveal sensitive information that could be present in a full URL, such as an org
ID. This feature works only for Chrome and Firefox. |
| HSTS for Salesforce Sites and Experience Cloud
Sites |
Requires HTTPS on Experience Cloud sites and Salesforce Sites.This
setting must be enabled in two locations: Enable HSTS for Salesforce Sites and
Experience Cloud sites in Session Settings. Enable Require Secure Connections
(HTTPS) in the Experience Cloud site or Salesforce Site security settings. See
Creating and Editing Salesforce
Sites. |
| Warn users before they are redirected outside of Salesforce |
Displays a warning message when users click links that take them outside the
salesforce.com domain. The warning message includes the full link to the external
URL and the domain name. Use this feature to protect your users from malicious
URLs and phishing. In Lightning Experience, the warning message applies only to
web tabs. |
| Logout URL |
Redirects users to a specific page after they logout of Salesforce, such as
an authentication provider’s page or a custom-branded page. This URL is used only
if no logout URL is specified in the identity provider, SAML single sign-on, or
external authentication provider settings. If no value is specified for Logout
URL, the default is https://login.salesforce.com, unless
MyDomain is enabled. If My Domain is enabled, the default is
https://customdomain.my.salesforce.com. |
| Link expires in |
Specifies how long the account verification link in welcome emails to new
users is valid. You can select 1, 7, or 180 days. By default, account verification
links expire after 7 days. When you update this setting, the change applies to
links in welcome emails that were already sent. For example, you added a user
and sent a welcome email two days ago when links expired in 7 days. If you
update the setting so that links expire in one day, the link in the email you
sent 2 days ago is no longer valid.
|
j