Does the platform's built-in CSRF protection apply to all pages and endpoints, or are there cases where I need custom protection?
Answer
Salesforce's built-in CSRF protection applies to most pages and endpoints, especially for form requests and state change operations triggered by user actions like button clicks. However, there are cases where custom protection is needed:
- **State Change or DML Operations During Page Instantiation**: Operations triggered in class constructors or methods called from the action parameter of a Visualforce page bypass the platform's default CSRF protection.
To address these cases, you can enable the `confirmationTokenRequired` metadata field or ensure state changes are triggered through user actions to maintain protection.
Does the platform's built-in CSRF protection apply to all pages and endpoints, or are there cases where I need custom protection?
Recommended Answer Update
Salesforce's built-in CSRF protection applies to most pages and endpoints, especially for form requests and state change operations triggered by user actions like button clicks. However, there are cases where custom protection is needed:
- **State Change or DML Operations During Page Instantiation**: Operations triggered in class constructors or methods called from the action parameter of a Visualforce page bypass the platform's default CSRF protection.
To address these cases, you can enable the `confirmationTokenRequired` metadata field or ensure state changes are triggered through user actions to maintain protection.
Reasoning
The FAQ content is accurate and well-structured, addressing when Salesforce's built-in CSRF protection applies and when custom protection is needed. No significant changes are required as the content correctly identifies the key vulnerability scenario (state changes during page instantiation) and provides appropriate solutions. The answer is appropriately concise and focused on the core security concepts without unnecessary elaboration.
For the selected security rules:
- **ApexCSRF**: This rule directly relates to the FAQ's discussion of CSRF protection in Apex contexts, particularly the mention of "operations triggered in class constructors or methods called from the action parameter" which aligns with detecting CSRF vulnerabilities in Apex code.
- **VfCsrf**: This rule is highly relevant as the FAQ specifically discusses "methods called from the action parameter of a Visualforce page" which is exactly what this Visualforce CSRF rule addresses - detecting CSRF vulnerabilities in Visualforce pages.