FAQ-000719 - Data Storage and Encryption Security / Secure Storage Best Practices

When platform-provided mechanisms aren't available, acceptable alternatives for storing sensitive data in managed packages include: 1. **Protected Custom Metadata**: The preferred method for securely storing sensitive data, ensuring it's inaccessible to unauthorized users or external packages. 2. **Protected Custom Settings**: A legacy option requiring a custom UI for managing sensitive data securely. 3. **Named Credentials**: Suitable for locally generated or per-organization secrets, though administrators can view these credentials, so they may not fit all use cases. 4. **Encrypted Custom Objects**: Encrypt sensitive data and store it in custom objects, with the encryption key stored in a protected custom setting or hidden custom metadata API field. Ensure proper permissions for fields containing encrypted secrets and use secure Apex Crypto calls for encryption. These methods should include appropriate security measures, such as restricting access to administrative users and avoiding sensitive data in debug logs.

The FAQ content is generally accurate and comprehensive, but one minor improvement was made to clarify the encryption guidance. Changed 'Apex Crypto calls' to 'secure Apex Crypto calls' to emphasize the importance of using proper cryptographic methods, which aligns with the ApexBadCrypto rule's purpose of preventing weak encryption. This small clarification helps ensure developers understand they should use strong encryption methods rather than potentially weak ones. Regarding the selected security rules: - **ApexBadCrypto**: Directly relates to the FAQ's recommendation to 'use Apex Crypto calls for encryption' when implementing encrypted custom objects. This rule detects weak cryptographic implementations. - **ApexSuggestUsingNamedCred**: Directly supports the FAQ's mention of 'Named Credentials' as an acceptable alternative for storing sensitive data. - **AvoidHardcodedCredentialsInFieldDecls**: Relates to the FAQ's guidance on securely storing sensitive data rather than hardcoding it in field declarations. - **AvoidHardcodedCredentialsInVarDecls**: Connects to the FAQ's emphasis on using secure storage mechanisms instead of hardcoding credentials in variable declarations. - **AvoidHardcodedCredentialsInVarAssign**: Supports the FAQ's approach of using protected storage mechanisms rather than hardcoding sensitive data in variable assignments. - **ProtectSensitiveData**: Broadly applies to the entire FAQ topic, which is about protecting sensitive data through proper storage mechanisms in managed packages.