Platform Security FAQs | Secure Coding Guide

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 browser is closed.

Why is the session cookie not set with HTTP Only flag?

You can require HttpOnly cookies for your organization. Go to Administer > Security > Session Settings > Session Setting and enable “RequireHttpOnly 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/Quality issues like these would not fall under security.

Most default data validation/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)

Communities have two clickjack protection parts—one for the Communities site which is set from the Salesforce site detail page and another for the Site.com Communities site which is set from the Site.com configuration page. It's recommended that both are set to the same value.

https://help.salesforce.com/articleView?id=siteforce_clickjacking_enable.htm&type=0

Cross Site Request Forgery

Does the platform have any Cross Site Request Forgery protections?

CSRF protection is enabled by default. You can view/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.

Apex and Visualforce XSS guidelines

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/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/fields to perform input encoding.

See Cross Site Scripting protections

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, you may be able to use external add-ons such as F-Secure Cloud Protection for Salesforce. F-Secure is a cloud-based security solution designed to complement the native security capabilities of the Salesforce platform. It monitors files and URLs that are uploaded to or downloaded from Salesforce.

Certain file types and upload/download behavior can be managed via ‘’’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/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 the links below.

REST API SOQL Reference: available here

SOQL Reference: available here

FRONTDOOR.JSP SID

frontdoor.jsp SID used via login.salesforce.com is a temporary session that can not 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 created it upon login )

You can see the documentation about this behavior here: https://help.salesforce.com/articleView?id=security_frontdoorjsp.htm&type=0

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.

X-XSS-Protection

The HTTP header can be turned on or off by each organization under Setup > Security Controls > Session Settings > Enable XSS Protection. This header prevents some Reflected Cross-Site Scripting attacks. It works with the same way as the CSP directive reflected-XSS.

If the browser detects a reflected XSS, it will block the content and show a blank page instead.

We do not consider the browser level XSS protections as adequate to properly secure against XSS. Different browsers have different ways of handling/parsing HTML and Javascript and the protections behave differently across browsers. We consider it imperative to implement XSS protections on the application and be as browser agnostic as possible. From a resource perspective, we consider it more efficient to maintain this approach, rather than split efforts in managing the various XSS behaviors/protections of different browsers.

Directive: reflected-XSS

The HTTP header can be turned on or off by each organization under Setup > Security Controls > Session Settings > Enable XSS Protection.

Supported by Chrome only. This directive blocks reflected Cross-Site Scripting attacks. It works the same way as the X-XSS-Protection header.

The same preference controls the X-XSS-Protection header and the reflected-XSS CSP directive.

Directive: referrer

Aloha only

This directive indicates that when going from Salesforce to a third party domain, the Referer 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 indicats 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.

Note: HSTS is enabled for authenticated traffic only on the App Servers ( your instance where your org resides ).

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 > Clickjacking 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?

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/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 for HTTPS and have de-prioritized 3DES for all production and sandbox instances. We still have 3DES available for backwards compatibility for some older clients that still require this, but will not select it unless the client does not support AES.

Salesforce customers with software that supports AES who are concerned about the potential use of 3DES can configure their software to not use the 3DES cipher. This will not only affect Salesforce requests, but also other websites that support 3DES cipher suites.

Salesforce is mitigating the Sweet32 vulnerability attack by periodically rotating the encryption key along with the connections.

Block Ciphers and the Birthday Bound

Salesforce Supported TLS Ciphers