FAQ-001666 - Security Best Practices and Field Management / Application Architecture and Design Security

Current Status:VALID_RESPONSEErrorUnable to AnswerSuggests Case

Current FAQ

Question
What are the key architectural considerations and design patterns for building secure managed packages that will pass Salesforce Security Review?
Answer
To design secure managed packages that pass Salesforce Security Review, follow these key architectural considerations: **Security Standards and Compliance:** - Adhere to industry best practices and Salesforce security guidelines - Ensure compliance with updated security standards and use newer API versions (48+) for features like `WITH SECURITY_ENFORCED` - Follow Lightning Ready certification requirements for new solutions **Secure Design Patterns:** 1. **Data Security**: Use encryption methods (named credentials, encrypted fields, crypto API) for sensitive data. Store secrets in protected custom settings or metadata, never in plain text 2. **Static Resources**: Include JavaScript and CSS files in static resources rather than loading from external CDNs or third-party endpoints 3. **Input Sanitization**: Sanitize all user inputs to prevent XSS attacks. Use encoding functions like `JSENCODE`, `HTMLENCODE`, `URLENCODE` 4. **Secure Communication**: Always use HTTPS/SFTP for external communications, avoid HTTP/FTP 5. **OAuth Implementation**: Use OAuth for integrations, requesting only minimum necessary permissions **Architectural Patterns to Avoid:** - Dynamic loading of third-party JavaScript/CSS from external sources - CSS directives that breach style isolation or namespace boundaries - JavaScript execution outside Salesforce domain or proper sandbox - Using `escape="false"` in Visualforce without proper encoding - Storing sensitive data in logs or exposing it in debug statements - Improper handling of remote site settings or arbitrary endpoints **Technical Architecture:** - Use Second-Generation Managed Packages (2GP) for better modularity and version control - Implement dynamic Apex, SOQL, and DML for compatibility across Salesforce editions - Design interfaces between base and extension packages carefully - Plan for entire application lifecycle including updates and future compatibility **Testing and Validation:** - Use automated security scanning tools like Salesforce Code Analyzer and Checkmarx - Perform comprehensive end-to-end testing including external endpoints - Test all solution components (external web apps, mobile clients, APIs) - Document false positives and provide detailed explanations **Security Review Preparation:** - Prepare architecture diagrams, solution documentation, and security scan reports - Provide test environments and credentials for external components - Include user documentation and company information security policies - Leverage Partner Security Portal resources and schedule office hours with security engineers By following these principles and avoiding common pitfalls like improper data storage, insufficient input sanitization, and namespace isolation violations, you can design secure managed packages that meet Salesforce's security requirements and pass the security review process.
Enhancing FAQ...

Enhancing FAQ with AI recommendations...

AI Recommended Enhancement

Related Security Rules (click to view)
ApexBadCryptoApexCRUDViolationApexInsecureEndpointApexSharingViolationsApexSOQLInjectionApexSuggestUsingNamedCredApexXSSFromEscapeFalseApexXSSFromURLParamAvoidHardcodedCredentialsInFieldDeclsAvoidHardcodedCredentialsInHttpHeaderAvoidHardcodedCredentialsInVarAssignAvoidHardcodedCredentialsInVarDeclsAvoidInsecureHttpRemoteSiteSettingAvoidOldSalesforceApiVersionsAvoidSecurityEnforcedOldApiVersionLoadCSSLinkHrefLoadJavaScriptHtmlScriptLoadJavaScriptIncludeScript
Question
What are the key architectural considerations and design patterns for building secure managed packages that will pass Salesforce Security Review?
Recommended Answer Update
To design secure managed packages that pass Salesforce Security Review, follow these key architectural considerations: **Security Standards and Compliance:** - Adhere to industry best practices and Salesforce security guidelines - Ensure compliance with updated security standards and use newer API versions (48+) for features like `WITH SECURITY_ENFORCED` - Follow Lightning Ready certification requirements for new solutions **Secure Design Patterns:** 1. **Data Security**: Use encryption methods (named credentials, encrypted fields, crypto API) for sensitive data. Store secrets in protected custom settings or metadata, never in plain text 2. **Static Resources**: Include JavaScript and CSS files in static resources rather than loading from external CDNs or third-party endpoints 3. **Input Sanitization**: Sanitize all user inputs to prevent XSS attacks. Use encoding functions like `JSENCODE`, `HTMLENCODE`, `URLENCODE` 4. **Secure Communication**: Always use HTTPS for external communications, avoid HTTP 5. **OAuth Implementation**: Use OAuth for integrations, requesting only minimum necessary permissions **Architectural Patterns to Avoid:** - Dynamic loading of third-party JavaScript/CSS from external sources - CSS directives that breach style isolation or namespace boundaries - JavaScript execution outside Salesforce domain or proper sandbox - Using `escape="false"` in Visualforce without proper encoding - Storing sensitive data in logs or exposing it in debug statements - Improper handling of remote site settings or arbitrary endpoints **Technical Architecture:** - Use Second-Generation Managed Packages (2GP) for better modularity and version control - Implement dynamic Apex, SOQL, and DML for compatibility across Salesforce editions - Design interfaces between base and extension packages carefully - Plan for entire application lifecycle including updates and future compatibility **Testing and Validation:** - Use automated security scanning tools like Salesforce Code Analyzer and Checkmarx - Perform comprehensive end-to-end testing including external endpoints - Test all solution components (external web apps, mobile clients, APIs) - Document false positives and provide detailed explanations **Security Review Preparation:** - Prepare architecture diagrams, solution documentation, and security scan reports - Provide test environments and credentials for external components - Include user documentation and company information security policies - Leverage Partner Security Portal resources and schedule office hours with security engineers By following these principles and avoiding common pitfalls like improper data storage, insufficient input sanitization, and namespace isolation violations, you can design secure managed packages that meet Salesforce's security requirements and pass the security review process.
Reasoning
The FAQ content is comprehensive and accurate. I made one minor clarification change: removed 'SFTP' from secure communications guidance and removed 'FTP' from insecure protocols to avoid, keeping the focus on web-based HTTP/HTTPS protocols which are most relevant for Salesforce managed packages. The original mention of SFTP/FTP was not incorrect but could be confusing since these file transfer protocols are less commonly used in typical Salesforce package integrations. Regarding security rules selected: ApexBadCrypto relates to the 'Use encryption methods (crypto API)' guidance. ApexCRUDViolation and ApexSharingViolations connect to the general security standards mentioned. ApexInsecureEndpoint and AvoidInsecureHttpRemoteSiteSetting relate to 'Always use HTTPS for external communications, avoid HTTP'. ApexSOQLInjection connects to 'Sanitize all user inputs' guidance. ApexSuggestUsingNamedCred relates to 'Use named credentials' for sensitive data. ApexXSSFromEscapeFalse and ApexXSSFromURLParam relate to 'Using escape="false" in Visualforce without proper encoding' and input sanitization. The various AvoidHardcodedCredentials rules relate to 'Store secrets in protected custom settings or metadata, never in plain text'. AvoidOldSalesforceApiVersions and AvoidSecurityEnforcedOldApiVersion relate to 'use newer API versions (48+)'. The LoadCSS and LoadJavaScript rules relate to 'Include JavaScript and CSS files in static resources rather than loading from external CDNs'.
Reasoning References
Recommended Related Articles