Salesforce Developer Security Csrf


// Salesforce - Developer - Security - Cross Site Request Forgery ( CSRF ):

Even though Salesforce includes protection against CSRF out of the box, it has 
one limitation.  Consider the following Visualforce page:

<apex:page controller="CSRF_Demo" sidebar="false" 
  action="{!performInitAction}" tabStyle="CSRF_Demo__tab">

and the following Apex code:

public void performInitAction() {
    try {
        String id = ApexPages.currentPage().getParameters().get('UserId');


        Personnel__c obj = [select id, Name FROM Personnel__c WHERE id = :id];
        Resource_Type__c rt= [select id from Resource_Type__c 
          where Name='Knight'][0];

        if(Personnel__c.sObjectType.getDescribe().isUpdateable()) {
  ; update obj;


Before the Visualforce page renders in the user’s browser, the performInitAction 
method is called. This function parses the UserId parameter supplied in the URL 
and uses it to update the user as a knight in the system.  Because this action 
is executed before the rest of the page loads, it bypasses the default CSRF p
rotections provided by the platform.  To prevent this issue, modify your 
application logic to remove any state-changing operations from the apex:page 
action handlers.

Furthermore, we have to change one of the <apex:outputLink> tag to either a 
commandButton tag, or a commandLink tag:

<apex:commandLink value="Knight This Squire" action="{!knightSquire}">
  <apex:param name="accId" value="{!}" assignTo="{!currPerId}"/>

The above code probably create a form.

Avoiding state changing operations in the Visualforce page action value enables 
your application to make use of the platform CSRF protection.

Luckily, Salesforce includes protections against CSRF out of the box.  All 
requests made on the platform are protected.  This is a setting in 
your Salesforce org that is enabled by default.  The protection can only be 
disabled by contacting Salesforce.  You can see the CSRF setting at "Setup -> 
Security Controls -> Session Settings".

With this setting enabled, whenever an Apex form is loaded, the platform 
includes a com.salesforce.visualforce.ViewStateCSRF parameter in the form, and 
the token is validated on submission.  This token is inline with the previously 
mentioned requirements.  It is unique per request, and unique per user.

Salesforce Platform Protections:

1. All POST requests are protected against CSRF by default on the platform.

2. Everytime an apex form is loaded, the platform includes a _CONFIRMATIONTOKEN 
   in the form and the token is validated on submit. 

3. Make sure no state changing operations are performed on page load (using 
   action formulations on GET requests). 

Salesforce platform protection testing:

1. Try opening the Edit Account page in salesforce and look for the  
   _CONFIRMATIONTOKEN on the form. 

2. Intercept the Submit requesdt via a web proxy.

3. See what happens when you edit the token value, remove it altogether and 
   replace it with a token from another user in the org. You can login as the 
   malicious CSRF user in your org from Setup-> Manage Users to get their 

In Vulnerable_CSRF, the delete operation is being performed on the page load 
action. This leads to a CSRF vulnerability because a vulnerable webpage can 
include GET links to /apex/vulnerable_CSRF?id=<AccountID> for all accounts in 
your org and can lead to deleting all accounts in the system. 

In Fixed_CSRF all delete actions require a unique, random, per user, per session 
CONFIRMATIONTOKEN value  that cannot be guessed by the attacker.

Within the platform, we have implemented an anti-CSRF token to 
prevent this attack. Every form includes a parameter containing a random string 
of characters as a hidden field. When the user submits the form, the platform 
checks the validity of this string and will not execute the command unless the 
given value matches the expected value. This feature will protect you when using 
all of the standard controllers and methods — but only for POST requests. GET 
requests are not protected with the anti-forgery token.

By protecting only POST requests, follows the convention and 
recommendation that GET requests be safe in that they do not alter significant 
data on the server side or have other significant side-effects. That is, you 
should not be using GET requests to change application state, and so GET 
requests should not need CSRF protection.
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License