Secure Coding Guideline For Salesforce Development


We strictly follow security guidelines recommende by Following documentation walks you through the most common security issues has identified while auditing applications built on or integrated with


1. Cross-Site Scripting

Cross-site scripting is a vulnerability that occurs when an attacker can insert unauthorized JavaScript, VBScript, HTML, or other active content into a web page viewed by other users. A malicious script inserted into a page in this manner can hijack the user’s session, submit unauthorized transactions as the user, steal confidential information, or simply deface the page. Cross-site scripting is one of the most serious and most common attacks against web applications today.


  • Existing Protection :

All standard Visualforce components (tags of the form <apex:…>) have anti-XSS filters in place.


  • Disabling escape on Visualforce tags :

By default, nearly all Visualforce tags escape the XSS-vulnerable characters. It is possible to disable this behavior by setting the optional attribute escape=”false“.


  • Programming Constructs That Are Not Protected From XSS

The following mechanisms do not have built-in XSS protections and you should take extra care when using these tags and objects. The reason is simply because these items were intended to allow the developer to customize the page by inserting script commands.


    • S-Controls and Custom JavaScript

If you write your own JavaScript or S-controls, the platform has no way to protect you. The   <apex:includeScript>  Visualforce component allows you to include a custom script on the page. In these cases be very careful to validate that the content is sanitized and does not include user-supplied data.

For example, the following snippet is extremely vulnerable as it is including user-supplied input as the value of the script text.

<apex:includeScript value=”{!$CurrentPage.parameters.userInput}” />


    • S-Control Template and Formula Tags

S-Controls give the developer direct access to the HTML page itself and includes an array of tags that can be used to insert data into the pages. When using the template and formula tags, all output is unfiltered and must be validated by the developer.

The general syntax of these tags is:  {!FUNCTION()}  or   {!$OBJECT.ATTRIBUTE} .


Since expressions are rendered on the server, it is not possible to escape rendered data on the client using JavaScript or other client-side technology.


The standard mechanism to do server-side escaping is through the use of the JSENCODE, HTMLENCODE, JSINHTMLENCODE, andURLENCODE functions or the traditional SUBSTITUTE formula tag.


If your application allows users to include HTML tags by design, you must exercise great caution in what tags are allowed. The following tags may allow injection of script code and should not be allowed:

  • <applet>
  • <body>
  • <embed>
  • <frame>
  • <script>
  • <frameset>
  • <html>
  • <iframe>
  • <img>
  • <style>
  • <layer>
  • <link>
  • <ilayer>
  • <meta>
  • <object>


For more information you can visit to following link


2. SQL Injection

SQL injection is a common application security flaw that results from insecure construction of database queries with user-supplied data. When queries are built directly with user data inlined or concatenated directly with the query text, instead of using type-safe bind parameters, malicious input may be able to change the structure of the query to bypass or change application logic. SQL injection flaws are extremely serious. A single flaw anywhere in your application may allow an attacker to read, modify or delete your entire database.

  •  To prevent a SOQL injection attack, avoid using dynamic SOQL queries. Instead, use static queries and bind variables.
  • If you must use dynamic SOQL, use the escapeSingleQuotes method to sanitize user-supplied input. This method adds the escape character (\) to all single quotation marks in a string that is passed in from a user. The method ensures that all single quotation marks are treated as enclosing strings, instead of database commands.


For more information you can visit to following link


3. Cross Site Request Forgery

Web browsers allow GET and POST requests to be made between different web sites. Cross-site request forgery (CSRF) occurs when a user visits a malicious web page that makes their browser send requests to your application that the user did not intend. This can be done with the src attribute of the IMG, IFRAME or other tags and more complicated requests, including POSTs, can be made using JavaScript. Because the browser always sends the relevant cookies when making requests, requests like this appear to originate from an authenticated user. The malicious site isn’t able to see the results of these requests, but if create, update or delete functionality can be triggered, the malicious site may be able to perform unauthorized actions.


Applications built on the Apex and Visualforce platforms are protected by default. Anti-CSRF protections are available for most major application platforms but are often not enabled by default.

For more information you can visit to following link


4. Secure Communications and Cookies

Applications hosted outside or which send or receive important information from other sites must use HTTPS. Any cookies set by your application for authentication, authorization, or which contain private or personally identifiable information must set the Secureflag to ensure they are only sent over HTTPS.

When the server sets cookies without the Secure attribute, the browser will send the cookie back to the server over either HTTP or HTTPS connections.

For applications that are available over both HTTP and HTTPS, users that enroll or sign-in through must be directed and restricted to use of the secure site only.

On your web server, disable weak cipher suites and vulnerable versions of SSL/TLS. requires exclusive use of SSLv3 or TLS 1.0 or greater. Disable all null, export, 40-bit or DES cipher suites.


Try to use HTTPS exclusively for your web application. It is difficult to properly secure sites that use HTTP for some features or pages. If HTTP is necessary, make the HTTP-accessible features unauthenticated or create a different session identifier for that portion of the site that is not tied to the secure session identifier. If your site or application has secure and insecure modes, users must be automatically opted-in to use the secure version exclusively.

 For more information you can visit to following link


5. Storing Sensitive Data

Sensitive data can include:

  • Passwords
  • Passphrases
  • Encryption keys
  • Purchase instruments, such as credit card numbers
  • Personal contact information such as names, phone numbers, email addresses, account usernames, physical addresses, and more
  • Demographic information such as income, gender, age, ethnicity, education
  • In some states and countries: machine identifying information such as MAC address, serial numbers, IP addresses, and more

Sensitive data is also called personally-identifying information (PII) or high business impact (HBI) data. What is considered sensitive data varies greatly from state to state and country to country. Various compliance standards, such as the Payment Card Industry (PCI) compliance standard, require special steps to be taken when collecting sensitive data in order to stay in compliance.

 If you must store passwords (including non-Salesforce passwords), note that storing them in plaintext or hashed (such as with the MD5 function) makes your application vulnerable to mass user exploitation if an attacker can get access (even just read-only access) to your database (such as through stealing a backup tape or SQL injection). Although a successful SQL injection or data exposure attack is a huge problem in itself, if the attacker can recover passwords from the data, they can transparently compromise user accounts on a mass scale.

There are two ways to protect sensitive data within

1. Custom Settings

Custom settings are similar to custom objects and enable application developers to create custom sets of data, as well as create and associate custom data for an organization, profile, or specific user. However, setting the visibility of the Custom Setting Definition to “Protected” and including it in a managed package ensures that it’s only accessible programmatically via Apex code that exists within your package. In order to allow authorized users to create and update sensitive information, create a Visualforce page that only accepts input and does not render the value back on the page. The “transient” keyword should be used to declare instance variables within Visualforce controllers to ensure they are not transmitted as part of the view state. Please refer to the following link for details:

Finally, configure the security settings for this page to ensure it’s only accessible by limited profiles on an as needed basis.


2. Apex Crypto Functions

The Apex crypto class provides algorithms for creating digests, MACs, signatures and AES encryption. When using the crypto functions to implement AES encryption, keys must be generated randomly and stored securely in a Protected Custom Setting. Never hardcode the key in within an Apex class.

For more information and examples for implementing the crypto class, please visit:


3. Encrypted Custom Fields

Encrypted custom fields are text fields that can contain letters, numbers, or symbols but are encrypted with 128-bit keys and use the AES algorithm. The value of an encrypted field is only visible to users that have the “View Encrypted Data” permission.

The disadvantage of this method to protect data is that you must request to enable encrypted fields on a per-org basis. Additionally, such fields are always accessible by administrative users.

General Guidance

When storing sensitive information on a machine:

  • Do not store any cryptographic keys used for protecting secrets in your application code.
  • Be cautious of the algorithms and ciphers used in any cryptographic operations.
  • Salt hashes, and if possible store salts and hashes separately.
  • Leverage strong platform cryptographic solutions.
  • Check if frameworks/platforms have already addressed the problem.
  • Use SSL/TLS to transmit sensitive data.


6. Arbitrary Redirect

Many sites have a mechanism for redirecting users to different pages on the site, or even to pages on different sites. For example, some sites use redirects to bring users back to where they were before in the event of an interruption in flow:

  1. Alice logs in, and begins using the site.
  2. Alice stops in the middle of some action A on page P. Alice heads out to lunch.
  3. Because the site has a 30-minute session expiration timeout, when Alice comes back her session has expired.
  4. Alice re-authenticates, and the login form contains a hidden field with the URL of page P: <form action=”login.jsp” method=”POST”>

When Alice logs in, the application sends a redirect response to P, so Alice can get right back to work: HTTP/1.1 302 Found. The problem arises when the application will redirect users to any URL indiscriminately. This allows attackers to craft URLs that may look legitimate, but which actually hide an attack.


The general solution to the problem is to constrain the range of URLs to which your redirector will redirect. Constraining URLs by hostname is easy; the best way to do it is by keeping a list of known-good hostnames and checking that a URL’s hostname matches one in the list. You can also limit by known-good schemes and by known-good paths (perhaps using a regular expression).


For more information you can visit to following link


7. Authorization and Access Control

Authorization and access control vulnerabilities can occur throughout a web application. These vulnerabilities occur whenever an attacker can access a resource that is restricted to only authenticated users. Some common ones are:

  • Directory traversal
  • Bypassing authorization mechanisms
  • Privilege escalation

The way these vulnerabilities appear in a web application can be application specific, but common authorization vulnerabilities do exist and can be tested for. Authorization/access control, and directory traversal were both cited in the 2010 CWE/SANS Top 25 Most Dangerous Programming Errors report.

Web servers confine users browsing a site to the web document root directory, the location of which is dependent upon the web server‘s operating system. Access to the filesystem is additionally restricted by the operating system’s Access Control Lists (ACLs), which define read, write, and execute permissions for files. These protections are in place to restrict the user browsing the site from accessing sensitive information on the server. However, a web application that uses server-side scripts could allow an attacker to read, write, and execute files on the system by subverting the executing script. This is typically possible because input parameters to the script are not validated. Subverting a script in order to traverse the directories of a server and read sensitive files such as /etc/passwd are commonly referred to as directory traversal attacks.

Many web applications use roles, which permit selective access to certain resources based on the type of user. A common set of roles would be an unauthenticated user, a user, and an administrator account. An unauthenticated user might only be allowed to access a login page. The user may be able to access all of a web application except for maintenance and configuration of the web application, which is restricted to the administrator role. Any time that an attacker can gain access to a resource that is denied to their role, they have performed an authorization mechanism bypass.


The simplest methods of protecting against directory traversal and other authorization and access control vulnerabilities are to validate user input and follow secure design principles. t is important to correctly identify the attack surface of your web application, which includes not only the intended user input, but also any values the user can modify and submit with a proxy, such as data in cookies, request information, hidden fields, etc. All of this data should be properly validated before proceeding with any routines.

8. Testing Object and Field Level Security Enforcement

Object (CRUD) and field (FLS) level security are configured on profiles and can be used to restrict access on object types and individual fields. developers should design their applications to enforce the organization’s CRUD and FLS settings, and to gracefully degrade if a user’s access has been restricted.

9. Single Sign On Security

Single sign on issues arise for developers integrating with when either the API Partner Server URL is not validated or SSL is not used when a non-native application calls back to an external server with a user’s session id. This may result in exposure of the API Session ID or Salesforce data to an attacker.


Many composite applications implement a form of Single-Sign-On (SSO) between and the external application. This transaction requires a minimum of two parameters in order to authenticate the external application. The first parameter is the API Session ID (SID), which is considered sensitive and is equivalent to a login and password. The SID is generated on a per session basis when a user logs in. The second is the API Partner Server URL (SOAP Endpoint). The API Partner Server URL is the URL of the SOAP endpoint that is associated with the user’s instance of Salesforce. Applications will then utilize the SID to represent that user in future API requests and the SOAP Endpoint to communicate with the appropriate API server.


There are two main security concerns that should be taken into consideration for single sign on transactions in this situation.

1. Because the SID is equivalent to a password steps should be taken to protect it from interception in transit. SSL (HTTPS) should be enforced for any transactions that transmit the SID, and the certificate should be evaluated to ensure that it is a valid certificate. This includes pages that could transmit the SID through the Referrer header. The API Session ID should never be transmitted to 3rd party sites such as Google Analytics.

2. The API Partner Server URL (SOAP Endpoint) is used to authenticate the application using the SID. An attacker can spoof the URL that includes the API Partner Server URL and SID and simply change the API Partner Server URL to a non-Salesforce server. The attacker, thus imitating a Salesforce endpoint can use this to steal any data that is sent to the malicious server. In order to prevent authentication and data transmission through a rogue endpoint, the API Partner Server URL should be validated to be a legitimate SOAP Server.

Below is the regular expression to validate legitimate API Partner Server URL servers:

  • https://[^/?]+\\.(sales|visual\\.)force\\.com/services/(S|s)(O|o)(A|a)(P|p)/(u|c)/.*

To summarize the above regular expression, it ensures that the URL starts with ‘https://’, followed by a character other than ‘/ ‘ or ‘?’ for 1 or more times, followed by a ‘.’, followed by ‘sales’ or ‘visual.’ followed by ‘’, followed by ‘u’ or ‘c’, followed by ‘/’. This will allow:

( Note: You can get the information in more detailed about the Secure Coding Guideline from the “” this document also you can go through the video from this link “