Loading
Salesforce now sends email only from verified domains. Read More

Salesforce CRM Services Platform Security FAQs

Publish Date: Jan 22, 2025
Description


The following documentation provides answers to common security questions for the App Cloud platform.

It also covers common false positive findings from 3rd party Security Assessments against the App Cloud platform.

 

Resolution

Table of Contents

 

 

Secure Cookies

Why are certain cookies served from the salesforce.com domain not set as secure or set as persistent?
There are several cookies that the platform uses to enhance functionality which do not contain any session information. They cannot be used to gain access or escalate privilege if altered or accessed by an attacker. The session cookie 'sid' is marked as secure and is non-persistent, (i.e. the cookie is deleted when the user quits the browser).

 

Why is the session cookie not set with HTTP Only flag?
You can require HttpOnly cookies for your Organization under Setup | Security Controls | Session Settings | Require HttpOnly attribute. This will set the HttpOnly attribute only for the SID session cookie.

 

Data Validation

Why is data from particular input fields not validated server side before saving in Objects?
Data Validation or Quality issues like these would not fall under security. Most default data validation or quality rules are enforced client side.

An example of this is updating a picklist value to a non defined value via the API or modifying a standard page edit POST.

Examples of data validation rules that are enforced server side:

  • Setting a lookup ID to a non existent record ID.
  • Data type for a field e.g cannot set a number field with text values.
  • Explicit data validation rules setup in Object Validation Rules or Apex Triggers.

 

Clickjacking

Does the platform have Clickjacking protection?
Clickjacking protection can be enabled via: Setup | Security Controls | Session Settings. It is enabled by default for all Salesforce setup pages.

You can set the clickjack protection for a site to one of these levels:

  • Allow framing by any page (no protection)
  • Allow framing by the same origin only (recommended)
  • Don’t allow framing by any page (most protection)


Salesforce Communities have two clickjack protection parts:

  • Force.com Communities site which is set from the Force.com site detail page
  • Site.com Communities site which is set from the Site.com configuration page. It's recommended that both are set to the same value.


For more information, see our Enable Clickjack Protection documentation.

 

Cross Site Request Forgery

Does the platform have any Cross Site Request Forgery protections?
CSRF protection is enabled by default. You can view or modify the setting via Setup | Security Controls | Session Settings.

 

Why are Salesforce CSRF tokens reused?
CSRF tokens are scoped to a particular user, entity operated on, and session and are re-used within a user's session.

The token itself is randomly generated such that it cannot be guessed by an attacker. It will be just as difficult for an attacker to get the user's sessionid as it is the CSRF token.

 

Cross Site Scripting

Does the platform have any Cross Site Scripting protections?
All standard pages output encode user controlled data in the proper context it is used in. For VisualForce pages , all merge fields are HTML encoded by default.

Any cross site scripting vulnerabilities that occur from custom VisualForce pages needs to be addressed with best practice recommendations and tools provided for developers.

Apex and VisualForce provide additional encoding utilities for other contexts. Developers are responsible for the proper output encoding for other non-html contexts.

For more information, see our Apex and VisualForce XSS guidelines documentation.


Why is data not input encoded on saving to Objects to protect against XSS?
The platform implements context specific output encoding for user controlled data. Salesforce data can be presented in multitude of contexts and systems, and it is a difficult challenge to successfully anticipate the correct context for data at input time.

Standard pages are designed to properly encode data in the correct context in which it is displayed. If input encoding is required, implement custom triggers on desired Objects or fields to perform input encoding.

 

File Upload

We are aware that it is possible for files uploaded by a malicious user to contain malicious content and a user who downloads the file could be compromised if antivirus software does not detect the file as malicious.

As an option, customers who would like to enhance their endpoint security by scanning files uploaded and downloaded from Salesforce  may do so by utilizing third party scanning products found in the Salesforce AppExchange. 

Certain file types and upload or download behavior can be managed under Setup | Security Controls | File Upload and Download Security. For other file types, custom Apex triggers on related Objects can limit the file extensions uploaded.

 

Are stored files scanned for malicious content?
Files are not scanned for malicious content. The data is stored as binary on Salesforce servers. Certain file types are parsed for search indexing or for preview display and controls have been put in place to ensure this occurs in an isolated environment with limited privileges.

The following resources may also be useful:


Files and attachments are stored within the services in such a manner that if something was uploaded which was infected, it would have no affect on the rest of the service or other files because of the way it is stored. So, we are protecting the platform, which is all we can do. We cannot control the customer's end points, and it is their responsibility to ensure that those endpoints have up to date antivirus protection.

The app layer is abstracted from the infrastructure layer via our multi tenant model, hence the reason we are speaking to two different parts, the infrastructure layer we manage and protect, and the app layer where users are able to upload anything they want, in a secure manner, but we can't control whether the user chooses to upload an infected file, or in the case of some of our customers, intentionally upload items which are known to be infected.

 

Arbitrary SQL query execution

The finding does not contain SQL, rather it contains SOQL so there is not a security impact..

The request is a call to our REST API which allows users to query Objects and fields that they already can access based on the access control settings that the Organization's administrator has set.

The REST API enforces the correct permissions including Sharing, CRUD, and FLS. Therefore nothing is exposed to the user that they would not already have permission to access, and no secrets, proprietary information or information useful to an attacker is exposed.

For more information on the REST API and SOQL Queries, please see:

FRONTDOOR.JSP SID

FRONTDOOR.JSP SID used via login.salesforce.com is a temporary session that cannot be used upon login. Salesforce is aware of the ability to login via frontdoor.jsp?sid=<sessionid> via the API (you will not be able to use the temporary session ID but the SID it created upon login).

For documentation about this behavior, please see Using Frontdoor.jsp to Log Into Salesforce​.

 

JSESSIONID

JSESSIONID is a temporary session ID and the cookie can not be exploited. The main session cookie is the SID and it is marked secure.

 

HTTP Headers

X-Content-Type-Options: no sniff
The HTTP header can be turned on or off by each Organization under Setup | Security Controls | Session Settings | Enable Content Sniffing Protection.

Browsers may ignore the Content-Type header returned by the server and guess the content-type from the actual content of the body response. This can be leveraged to force the browser to execute malicious JavaScript or CSS.

The HTTP header X-Content-Type-Options: nosniff prevents the browser from guessing the type of file based on its content or the embedding tag. The browser obeys the content-type sent by the server.


Directive: referrer

Aloha only
This directive indicates that when going from Salesforce to a third party domain, the Referrer header should contain only the Salesforce domain, not the full URL. This prevents leaking confidential information from the URL to other sites when loading assets (images, scripts) or clicking on a link.

Referrer: https://domain.my.salesforce.com/page.jsp?oid=XXXXXX&secret=YYYYY becomes Referrer: https://domain.my.salesforce.com

The Referrer header is unchanged within the same domain.
 

HTTP Public Key Pinning

Public Key Pinning (HPKP) allows a website to declare the list of valid certificates for this website in the HPKP header sent to the server. Like HSTS, this information is valid for the amount of time specified in the HPKP header.

The HPKP header contains a hash of all the valid public keys from any of the SSL certificate in the chain. Like CSP, it is possible to report only violations and/or to block certificates mismatches.

Salesforce uses HPKP in report-only mode. No content is blocked if the certificate does not match any of the PINs.
 

Content Security Policy (CSP) - Reporting

Aloha only
The Content-Security-Policy-Report-Only response header allows Salesforce to monitor the use of third party assets in order to detect HTTP contents loaded on HTTPS websites.

This header defines a policy. The policy is checked by the browser (Chrome, Firefox, and Safari - not Internet Explorer) on each page but not enforced. The browser sends a report to Salesforce for each policy violation. This header is enabled by default on all pages (Aloha). Lightning enforces its own CSP.

The Content Security Policy is made of several directives. In Aloha, the directives indicate that assets (images, web fonts, style sheets, etc.) can be loaded over HTTPS or inline.

The frame-ancestor directive indicates that only salesforce.com and force.com should include an IFRAME of Salesforce services.
 

HTTP Strict Transport Security (HSTS)

HSTS is enabled for login.salesforce.com, MyDomains, on Lightning + content domain, VisualForce, Communities subdomain and on the non-community, Sites subdomain.

The HSTS for all Sites and Communities can be enabled under Setup | Security Controls | Session Settings | Enable HSTS for all Sites and Communities with the default force.com subdomain that require a secure connection (HTTPS)

The HSTS for all Custom Domains can be enabled under  Setup | Domain Management | Click on Domain Name | Enable Strict Transport Security Headers
 

X-FRAME Options Header

Customers can prevent the inclusion of Salesforce IFRAMEs on third-party site by enabling 'Prevent Clickjacking' under Security Controls | Session Settings | Clickjack Protection.

We recommend customer to enable this feature for all VisualForce pages.

 

Miscellaneous

Caching: Why are certain HTTP responses from the platform cached by browsers? ( Cache-Control set to Private )
Salesforce caches for performance reasons and this is controlled via HTTP header cache response directives. The main security issue here is if an attacker gains access to the local client machine.

To mitigate access to the cached data in this scenario, configure user browsers to not cache requests. We review on a case by case basis whether certain pages or resources should not be cached based on the content being cached.

 

Will Salesforce deprecate use of RC4 and 3DES ciphersuites?
We no longer support RC4 and 3DES ciphers for HTTPS.

Knowledge Article Number

000383448

 
Loading
Salesforce Help | Article