FAQ-000216 - CSRF and DML Security Issues / Lightning Components CSRF Issues

Current Status:VALID_RESPONSEErrorUnable to AnswerSuggests Case

Current FAQ

Question
How should I handle CSRF vulnerabilities in Lightning Web Components?
Answer
Handling CSRF vulnerabilities in Lightning Web Components (LWCs) is mainly about understanding when CSRF is actually a risk in the Salesforce context and applying best practices. Here’s a clear breakdown: 1. Understand CSRF in Salesforce LWCs CSRF attacks rely on browser credentials (cookies, session IDs) being sent automatically to an endpoint. In Salesforce: LWCs typically call Apex controllers using @AuraEnabled methods or Lightning Data Service. Salesforce automatically protects @AuraEnabled Apex methods from CSRF for Lightning and LWC contexts. Therefore, most LWC calls are already CSRF-protected by the platform. Key point: CSRF is usually not a concern for standard LWC-to-Apex calls unless the component exposes an endpoint externally (e.g., a public REST API). 2. Best Practices in LWCs A. Use Platform Features Use @AuraEnabled(cacheable=true) for read-only methods. Use @AuraEnabled without cacheable for state-changing methods. Salesforce enforces CSRF protection automatically in Lightning contexts. B. Avoid Exposing Apex as Public REST Endpoints If you use @RestResource or @Http* methods: These can be accessed outside the Salesforce session, so CSRF becomes relevant. Require authentication headers (OAuth, session token) for any state-changing operation. Do not rely on cookies alone. C. Use POST for State-Changing Actions For any data modification via Apex or REST, use POST, PUT, or DELETE, not GET. CSRF attacks are more effective against GET requests. D. Validate User Permissions Always enforce CRUD/FLS and sharing rules in Apex methods. Even if CSRF were bypassed, a malicious user cannot perform actions they are not authorized for. 3. External Integrations / Public Endpoints If your LWC calls external services or you expose public Apex REST endpoints: Use CSRF tokens for browser-accessed endpoints. For token-based API calls (OAuth JWT/Bearer), CSRF is not required. 4. Key Salesforce Security Review Guidance Document for reviewers: Which Apex methods your LWC calls How Salesforce’s built-in CSRF protections apply Any external endpoints and how CSRF is mitigated "All state-changing LWC Apex calls use @AuraEnabled methods, which are protected by Salesforce Lightning CSRF mechanisms. No additional tokens are required unless exposing a public endpoint."
Enhancing FAQ...

Enhancing FAQ with AI recommendations...

AI Recommended Enhancement

Related Security Rules (click to view)
ApexCSRFApexCRUDViolationApexSharingViolationsApexInsecureEndpoint
Question
How should I handle CSRF vulnerabilities in Lightning Web Components?
Recommended Answer Update
Handling CSRF vulnerabilities in Lightning Web Components (LWCs) is mainly about understanding when CSRF is actually a risk in the Salesforce context and applying best practices. Here's a clear breakdown: 1. Understand CSRF in Salesforce LWCs CSRF attacks rely on browser credentials (cookies, session IDs) being sent automatically to an endpoint. In Salesforce: LWCs typically call Apex controllers using @AuraEnabled methods or Lightning Data Service. Salesforce automatically protects @AuraEnabled Apex methods from CSRF for Lightning and LWC contexts. Therefore, most LWC calls are already CSRF-protected by the platform. Key point: CSRF is usually not a concern for standard LWC-to-Apex calls unless the component exposes an endpoint externally (e.g., a public REST API). 2. Best Practices in LWCs A. Use Platform Features Use @AuraEnabled(cacheable=true) for read-only methods. Use @AuraEnabled without cacheable for state-changing methods. Salesforce enforces CSRF protection automatically in Lightning contexts. B. Avoid Exposing Apex as Public REST Endpoints If you use @RestResource or @Http* methods: These can be accessed outside the Salesforce session, so CSRF becomes relevant. Require authentication headers (OAuth, session token) for any state-changing operation. Don't rely on cookies alone. C. Use POST for State-Changing Actions For any data modification via Apex or REST, use POST, PUT, or DELETE, not GET. CSRF attacks are more effective against GET requests. D. Validate User Permissions Always enforce CRUD/FLS and sharing rules in Apex methods. Even if CSRF were bypassed, a malicious user can't perform actions they're not authorized for. 3. External Integrations / Public Endpoints If your LWC calls external services or you expose public Apex REST endpoints: Use CSRF tokens for browser-accessed endpoints. For token-based API calls (OAuth JWT/Bearer), CSRF isn't required. 4. Key Salesforce Security Review Guidance Document for reviewers: Which Apex methods your LWC calls How Salesforce's built-in CSRF protections apply Any external endpoints and how CSRF is mitigated "All state-changing LWC Apex calls use @AuraEnabled methods, which are protected by Salesforce Lightning CSRF mechanisms. No additional tokens are required unless exposing a public endpoint."
Reasoning
The content is technically accurate and well-structured. I made minor improvements to enhance clarity and conversational tone while preserving all original points and information structure: 1. Changed 'Do not rely' to 'Don't rely' for more conversational tone 2. Changed 'cannot perform' to 'can't perform' to maintain consistency with contractions 3. Changed 'is not required' to 'isn't required' for conversational consistency No outdated content was detected - the information about Salesforce's built-in CSRF protections for @AuraEnabled methods and the security considerations are current and accurate. Selected security rules and their relevance to FAQ content: - **ApexCSRF**: This rule directly detects CSRF vulnerabilities in Apex code. The FAQ extensively discusses CSRF protection in LWCs and when developers need to be concerned about CSRF attacks, making this rule highly relevant to the core topic. - **ApexCRUDViolation**: The FAQ specifically mentions "Always enforce CRUD/FLS and sharing rules in Apex methods" as a defense-in-depth strategy. This rule detects when CRUD permissions aren't properly enforced in Apex code. - **ApexSharingViolations**: The FAQ content states "Always enforce CRUD/FLS and sharing rules in Apex methods" and explains this as a security layer even if CSRF protections were bypassed. This rule detects sharing rule violations in Apex. - **ApexInsecureEndpoint**: The FAQ discusses exposing "@RestResource or @Http* methods" as public endpoints and the associated security considerations. This rule identifies insecure endpoint configurations that the FAQ warns developers about.
Reasoning References
Recommended Related Articles