FAQ-001652 - Salesforce Platform Security Responsibility / Standard Salesforce Components and Profiles

**For Standard Salesforce Profiles:** When security reviews flag standard profiles like System Administrator: 1. **Why This Happens**: Permissions on standard profiles might be flagged if your app's logic explicitly relies on or checks for this profile. For instance, if your code includes conditions like `profile = System Administrator` to bypass CRUD/FLS checks, it could fail when the profile name is localized or altered. 2. **How to Address**: - Avoid relying solely on profile-based logic, as this approach can fail in scenarios where language settings differ - Implement explicit CRUD/FLS checks to ensure compliance with security standards - Use `Schema.sObjectType` to verify field accessibility before performing DML operations - Ensure your code explicitly checks for CRUD/FLS permissions, even if designed for system administrators **For Standard Salesforce Objects and Fields:** To handle security scanner findings for standard objects and fields: 1. **CRUD and FLS Checks**: Ensure that Create, Read, Update, Delete (CRUD) and Field-Level Security (FLS) checks are properly implemented 2. **SOQL Queries**: Use `WITH USER_MODE` for SOQL queries to automatically enforce CRUD/FLS checks. For older API versions, you can use `WITH SECURITY_ENFORCED` for SELECT and FROM fields, though this requires manual `isAccessible()` checks for WHERE and ORDER BY fields 3. **Respect Sharing Rules**: Use appropriate sharing settings like "with sharing" or "inherited sharing" to ensure sharing rules are respected 4. **Document False Positives**: Clearly document any false positives with detailed explanations and use cases to justify them **Standard Configurations That Might Be Incorrectly Flagged:** - False positives from automated scanning tools like Source Code Scanner, ZAP, or Burp Suite - Sensitive data in standard SObject fields (e.g., First Name, Last Name) in unencrypted form - Debug logs containing customer information in standard schema fields - VisualForce pages using `escape="false"` when output is correctly encoded - Medium-severity issues like sensitive data in URLs (excluding session IDs or credentials) - Code quality issues flagged in Code Analyzer reports but not actual security concerns **For Components Not in Your Package:** I couldn't find specific guidance on handling security findings related to standard profiles, objects, or components that aren't part of your package. You may want to open a case with Salesforce for clarification and specific documentation requirements. **Why Standard Features Might Be Flagged:** A standard feature like the Consumer Key on a Connected App might be flagged as insecurely stored if it isn't adequately protected (e.g., stored unencrypted, written to debug logs, or passed in URLs). The review emphasizes secure storage practices using protected custom settings or encryption mechanisms.

The main improvement needed was updating the SOQL security guidance to prioritize modern features. The original text mentioned `WITH SECURITY_ENFORCED` as the primary approach, which is now considered legacy. According to the security approaches guidelines, I should 'prioritize modern features over legacy approaches' and 'lead with WITH USER_MODE for SOQL queries.' I updated the SOQL section to recommend `WITH USER_MODE` first while preserving the existing information about `WITH SECURITY_ENFORCED` as a valid alternative for older API versions. For the related security rules: 1. **ApexCRUDViolation**: This rule directly relates to the FAQ's extensive discussion of CRUD/FLS checks, including the sections about implementing explicit CRUD/FLS checks, using Schema.sObjectType for field accessibility, and ensuring proper permission validation. 2. **ApexSharingViolations**: This rule corresponds to the FAQ's guidance on respecting sharing rules through appropriate sharing settings like 'with sharing' or 'inherited sharing'. 3. **AvoidSecurityEnforcedOldApiVersion**: This rule is relevant because the FAQ discusses `WITH SECURITY_ENFORCED` and security enforcement approaches, and this rule specifically addresses concerns about using security enforcement features with older API versions.