Handling sensitive data — whether it’s personal information, encryption keys, or API tokens — is a critical responsibility for developers working in the Salesforce ecosystem. Mishandling this data can lead to serious security breaches, so knowing the right strategies for storage isn’t just about compliance — it’s about keeping your users' trust intact.
In this blog, we’ll break down what qualifies as “sensitive data” and explore secure methods Salesforce provides to manage it, helping you safeguard information and meet your app’s specific needs.
What is Sensitive Data?
Sensitive data refers to any information that must be kept safe and inaccessible to unauthorized individuals. This can include personal, legal, or financial details, as well as project-specific information that requires restricted access.
The definition of sensitive data can vary by country, state, or compliance standards. Examples of sensitive data include, but are not limited to:
Passwords
Passphrases
Encryption keys
OAuth tokens
How to Securely Store Sensitive Data in Salesforce
When developing AppExchange applications, certain sensitive data (such as API secrets) must be protected from unauthorized access. Salesforce provides several options for securely storing and retrieving this data, depending on your app’s requirements:
Protected Custom Metadata Types
Custom metadata types, when included in a managed package and marked as protected, are not visible to subscribing organizations through Apex or the API. These are only accessible by Apex code within the same package, making them ideal for storing secrets like API keys. Subscribers cannot see the secret data used within the package.
For example, a common mistake is to store tokens directly in the code:
apex
Copy code
public with sharing class SampleIntegrationService { private static final String appToken = ‘exampleToken’; }
A better approach would be to use protected custom metadata to store tokens, app secrets, and other sensitive information, ensuring alignment with Salesforce's security requirements.
Storage Limit: 10 million characters per package
Advantages:
Secure storage of application secrets (API keys, tokens)
Support for complex data structures, custom fields, and relationships
Efficient access with cached data, avoiding governor limits
Disadvantages:
More complex deployment when changes are needed
No dynamic updates at runtime (requires package versioning)
For more information, refer to Salesforce Custom Metadata Protection.
Protected Custom Settings
Custom settings are useful when sensitive data is created by the client and needs to be securely stored in Salesforce. AppExchange apps can have a UI to collect client data and store it securely in protected custom settings. External code or logic cannot modify these settings.
Types of Custom Settings:
List Custom Settings: Store org-wide sensitive data (e.g., integration details used by all users).
Hierarchical Custom Settings: Store data at user, profile, or org levels (e.g., user-specific integration details).
Compared to custom metadata, custom settings are easier to update through Apex, making them more dynamic and flexible in certain use cases.
Storage Limit: 6 MB per package
Advantages:
Secure and hidden data storage
Cached data for improved performance
Easy maintenance without widespread code changes
Disadvantages:
Data migration and setup require post-install scripts For more information, refer to Salesforce Custom Settings.
For more information, refer to Salesforce Custom Settings.
Named Credentials
Named credentials offer a secure, declarative way to manage authentication details for external services. They store the callout URL and authentication parameters and support various authentication protocols like OAuth 2.0 and JWT.
Salesforce recently introduced a separation between the URL (stored in Named Credentials) and authentication parameters (stored in External Credentials), making it easier to maintain and reuse authentication settings across multiple endpoints.
Storage Limit: Not applicable
Advantages:
Declarative storage of external authentication details
Multiple endpoints can share authentication parameters
Disadvantages:
Users with "Customize Application" permission can view named credentials, which may pose a security risk. Use protected custom settings or metadata for stricter security.
For more details, see Named Credentials Packaging Guide.
Custom Objects (For Special/Exception Scenarios)
In cases where large volumes of sensitive data need to be stored, custom objects may be the solution. To secure data within custom objects, Apex Crypto functions can be used to encrypt sensitive information, with the encryption key stored in protected custom metadata.
Use Case: If a large-scale application needs to store secret records, the encryption key can be safely stored in protected custom metadata, with custom objects used for the data itself.
Storage Limit: No limit
Advantages:
No package-specific storage limits
Disadvantages:
Data can be viewed or deleted by admins
Encryption and decryption require custom code
At a Glance
By carefully selecting the right storage method, you can ensure that sensitive data is handled securely within Salesforce, protecting both your app and its users.
To know more about Extentia's Salesforce expertise, visit https://www.extentia.com/salesforce
Comments