FAQ-001640 - Salesforce Platform Security Responsibility / False Positive Identification and Documentation

Current Status:VALID_RESPONSEErrorUnable to AnswerSuggests Case

← Back to List View Prompt Template

Current FAQ

Question
How can I distinguish between security vulnerabilities in my managed package code versus underlying Salesforce platform functionality?
Answer
To distinguish between security vulnerabilities in your managed package code and Salesforce platform functionality: 1. **Managed Package Vulnerabilities**: - These arise from custom code or configurations within your package - Examples include improper CRUD/FLS checks, insecure storage of sensitive data, direct DOM manipulation, or SOQL injection - These are your responsibility to address and resolve - Use tools like Salesforce Code Analyzer and Checkmarx scanner to identify these issues 2. **Salesforce Platform Functionality Vulnerabilities**: - These relate to inherent risks or limitations within the Salesforce platform itself - Examples include SQL Injection or Path Traversal related to platform behavior, use of `userinfo.getsessionId` for Metadata API access, or certain CRUD/FLS checks that align with approved platform use cases - They are outside your control as a managed package developer 3. **How to Determine False Positives**: - Document responses for each flagged issue, providing code location and explaining why the flagged code does not pose a security vulnerability - False positives often occur when security-scanning tools flag code that appears vulnerable but is not exploitable or is required for valid functionality - Focus on relevant issues - some scan categories like "Code Quality" in Checkmarx do not require attention 4. **Next Steps**: - For managed package vulnerabilities, ensure compliance with Salesforce's secure coding guidelines - For platform-related issues, document them with proper justification and communicate with Salesforce through appropriate channels - Use the False Positive Documentation template to ensure clarity and completeness

Enhancing FAQ with AI recommendations...

AI Recommended Enhancement

Related Security Rules (click to view)
ApexCRUDViolationApexSharingViolationsApexSOQLInjectionApexXSSFromEscapeFalseApexXSSFromURLParamAvoidUnauthorizedGetSessionIdInApexAvoidUnauthorizedApiSessionIdInApexVfUnescapeEl
Question
How can I distinguish between security vulnerabilities in my managed package code versus underlying Salesforce platform functionality?
Recommended Answer Update
To distinguish between security vulnerabilities in your managed package code and Salesforce platform functionality: 1. **Managed Package Vulnerabilities**: - These arise from custom code or configurations within your package - Examples include improper CRUD/FLS checks, insecure storage of sensitive data, direct DOM manipulation, or SOQL injection - These are your responsibility to address and resolve - Use tools like Salesforce Code Analyzer and Checkmarx to identify these issues 2. **Salesforce Platform Functionality Vulnerabilities**: - These relate to inherent risks or limitations within the Salesforce platform itself - Examples include SQL Injection or Path Traversal related to platform behavior, use of `UserInfo.getSessionId()` for Metadata API access, or certain CRUD/FLS checks that align with approved platform use cases - They're outside your control as a managed package developer 3. **How to Determine False Positives**: - Document responses for each flagged issue, providing code location and explaining why the flagged code doesn't pose a security vulnerability - False positives often occur when security-scanning tools flag code that appears vulnerable but isn't exploitable or is required for valid functionality - Focus on relevant issues - some scan categories like "Code Quality" in Checkmarx don't require attention 4. **Next Steps**: - For managed package vulnerabilities, ensure compliance with Salesforce's secure coding guidelines - For platform-related issues, document them with proper justification and communicate with Salesforce through appropriate channels - Use the False Positive Documentation template to ensure clarity and completeness
Reasoning
The FAQ content is generally accurate and well-structured. I made several minor improvements for clarity and conversational tone: 1. **Tone and clarity improvements**: Updated "userinfo.getsessionId" to proper case "UserInfo.getSessionId()" for accuracy, changed "They are outside your control" to "They're outside your control" for conversational tone, and adjusted "do not require attention" to "don't require attention". 2. **Security rules selection reasoning**: I selected 8 rules that directly relate to the types of managed package vulnerabilities discussed in the FAQ: - **ApexCRUDViolation**: Relates to the FAQ's mention of "improper CRUD/FLS checks" as managed package vulnerabilities - **ApexSharingViolations**: Connected to the FAQ's discussion of sharing-related security issues - **ApexSOQLInjection**: Directly corresponds to the FAQ's example of "SOQL injection" as a managed package vulnerability - **ApexXSSFromEscapeFalse** and **ApexXSSFromURLParam**: Related to the FAQ's mention of "direct DOM manipulation" and XSS vulnerabilities - **AvoidUnauthorizedGetSessionIdInApex** and **AvoidUnauthorizedApiSessionIdInApex**: Directly relate to the FAQ's specific example of "use of UserInfo.getSessionId() for Metadata API access" as platform functionality - **VfUnescapeEl**: Connects to the broader discussion of security vulnerabilities in custom code that scanners might flag Each selected rule corresponds to specific security vulnerability types mentioned in the FAQ, making them highly relevant for developers trying to distinguish between their code issues and platform-related false positives.
Reasoning References
Recommended Related Articles