FAQ-000263 - CSRF and DML Security Issues / Visualforce CSRF Protection

Common causes of Cross-Site Request Forgery (CSRF) vulnerabilities in Visualforce pages include: 1. **State Changes on Initialization**: Performing state changes or DML operations during page initialization, such as in class constructors or methods called from the `action` parameter of a Visualforce page. This bypasses the platform's default CSRF protection. 2. **CSRF Token Not Required**: Not enabling the `confirmationTokenRequired` boolean metadata field in the Visualforce page settings. Without this, GET requests to the page don't require a CSRF token, leaving it vulnerable. 3. **JavaScript Actions**: Actions submitted via JavaScript, as Visualforce's built-in CSRF protection doesn't cover these actions. To mitigate these vulnerabilities, enable the `confirmationTokenRequired` field, avoid state changes or DML operations during initialization, and ensure actions are triggered by user interactions.

The existing FAQ content is accurate and comprehensive. I made minor improvements to make the language more conversational by changing 'do not require' to 'don't require' and 'does not cover' to 'doesn't cover', following the brand guidelines to use contractions and be more conversational. These small changes maintain the technical accuracy while making the content more accessible. For security rules selection: - ApexCSRF: This rule directly relates to CSRF vulnerabilities in Apex controllers, which is exactly what the FAQ discusses. The FAQ content about performing state changes during initialization, not requiring CSRF tokens, and JavaScript actions all align with what this rule detects. - VfCsrf: This rule specifically targets CSRF vulnerabilities in Visualforce pages, which is the exact focus of this FAQ. The FAQ's discussion of the confirmationTokenRequired field and Visualforce-specific CSRF protection mechanisms directly corresponds to what this rule addresses.