| 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, do not select 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 a community 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 does not apply to API requests. All API requests require HTTPS.
To enable HTTPS on communities and Salesforce Sites, see HSTS for Sites and Communities.
- 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 is
not 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 is not 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.
If you disable this setting, 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
for all orgs.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 org’s users select their
profile picture. This setting is selected by default for all orgs. 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 authenticate with a physical security key
(U2F) |
Permits the use of a U2F security key for
two-factor authentication 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 a USB 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
two-factor authentication (2FA) registration |
Requires users to confirm their
identities to add a two-factor authentication 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 Lightning Communities) |
Requires external users to confirm that they
own the new email address. When users change their email address, they receive an
email at the new email address with a link. After they click the link, their new
email address takes effect. 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. |
| 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 is not 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. |
| 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 whitelisted external domains. To enable this feature,
whitelist external domains where you allow framing under Whitelisted Domains for
Visualforce 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 whitelisted external domains. To enable this
feature, whitelist external domains where you allow framing under Whitelisted
Domains for Visualforce 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 for all
orgs. |
| Enable CSRF protection on POST
requests on non-setup pages |
| Enable Stricter Content Security Policy |
The Lightning Component framework already 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 also prohibits the use of
unsafe-inline for script-src to mitigate the risk of cross-site
scripting attacks. |
| 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 Sites and Communities |
Requires HTTPS on communities and Salesforce Sites.This setting must be
enabled in two locations: Enable HSTS for Sites and Communities in Session
Settings. Enable Require Secure Connections (HTTPS) in the community 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 seven days. If you
update the setting so that links expire in one day, the link in the email you
sent two days ago is no longer valid.
|
j