FAQ-000204 - CSRF and DML Security Issues / General CSRF Prevention and Best Practices

To prevent cross-site request forgery (CSRF) attacks in Salesforce integrations, follow these best practices: 1. **Enable `confirmationTokenRequired`**: Protect state-changing operations by requiring a confirmation token. 2. **User-Initiated Actions**: Trigger state changes only through explicit user actions, like button clicks, instead of automatic actions on page load. 3. **Avoid DML in Constructors**: Don't perform data manipulation language (DML) operations in methods that are automatically initiated, such as constructors or page instantiation methods. 4. **Include CSRF Protection**: Ensure all form requests and state-changing controllers have CSRF protection mechanisms. 5. **Use Built-In Protections**: For Visualforce pages, use Salesforce's built-in CSRF protection and avoid JavaScript actions that bypass these safeguards. These steps will help secure your integrations against unauthorized actions during authenticated sessions.

The FAQ content is technically accurate and well-structured. I made minor wording improvements to enhance clarity and readability: changed 'Refrain from performing' to the more direct 'Don't perform', changed 'Leverage Built-In Protections' to 'Use Built-In Protections' for simpler language, and refined a few other phrases for better flow. The content aligns well with CSRF prevention best practices. For security rules selection: - ApexCSRF: This rule directly relates to the FAQ's core topic of preventing CSRF attacks in Salesforce integrations. The FAQ discusses avoiding DML in constructors and requiring user-initiated actions, which are exactly the types of CSRF vulnerabilities this rule detects. - VfCsrf: This rule is highly relevant as the FAQ specifically mentions 'For Visualforce pages, use Salesforce's built-in CSRF protection' and discusses form requests with CSRF protection, which directly corresponds to what this Visualforce CSRF rule addresses.