Why not to use Action attribute in VF tag

Today we will discuss that why the ‘action’ attribute should not be used in <apex:page> tag. But, before that we will discuss what exactly does the ‘action’ attribute do.

Salesforce provides a way to define logic before rendering a visualforce page by providing a special attribute called as ‘action’. It is used to define Page-Load actions. This attribute is available for other visualforce tags also, but here we will be discussing action attribute in ‘apex: page’ tag. This takes the name of the controller method as value and it controls how the Visualforce page should be displayed or any logic to be performed before page loads. This method is called before the page is rendered, and allows to optionally redirect the user to another page or perform some required calculation. Below is a code snippet for the same in Lightning Platform Applications.

VF Page:

<apex:page controller=”myClass” action=”{!init}”>




public class myClass {

public void init() {

Id id = ApexPages.currentPage().getParameters().get(‘id’);

Account obj = [select id, Name FROM Account WHERE id = :id];

delete obj;

return ;



Before the Visualforce page renders in the user’s browser, the init method from myClass.cls is called. In the above custom controller the object ID is used as an input parameter, then that input parameter is used in a SOQL call.

Unfortunately, since this action executes before the rest of the page loads, it bypasses the default CSRF(Cross Site Request Forgery) protections provided by the platform. The developer has bypassed the built-in defenses without realizing the risk. No anti-CSRF token was included in the request.

There are no built-in defenses for situations like this and developers should be cautious about writing pages that take action based upon a user-supplied parameter like the id variable in the preceding example.

A possible work-around is to insert an intermediate confirmation page before taking the action, to make sure the user intended to call the page. Other suggestions include shortening the idle session timeout for the organization and educating users to log out of their active session and not use their browser to visit other sites while authenticated.

Leave a Reply

Your email address will not be published. Required fields are marked *