it leads me to here: Is encrypting passwords in protected custom settings a security requirement?
Which includes this segment:
Ensure that sensitive information is not available to all users in a customer org. This can be achieved by using Custom Settings in “Protected” mode, and creating a Visualforce page for authorized users to update information. The previously stored data should not be displayed back to the user on this page. Another option is to implement Apex Crypto and store the encryption key in a protected custom setting. For more information see the Secure Cloud Development entry for Storing Secrets.
Having read all that, I don’t know what a protected custom setting record is. Are we talking about an Apex class, or something I store in a database somewhere?
Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.
To understand what custom settings are in the first place, have a read of Create Custom Data Sets:
Custom settings are similar to custom objects in that they let you customize org data. Unlike custom objects which have records based on them, custom settings let you utilize custom data sets across your org, or distinguish particular users or profiles based on custom criteria.
Custom settings data is exposed in the application cache, which enables efficient access without the cost of repeated queries to the database. This data can then be used by formula fields, validation rules, flows, Apex, and the SOAP API
As for what a protected custom setting is, take a look at Define Custom Settings:
- Visibility—Select a visibility of Protected or Public.
- Protected—If the custom setting is contained in a managed package, subscribing organizations can’t see the custom setting: it doesn’t display as part of the package list. In addition, subscribing organizations can’t access the custom setting using either Apex or the API, however, developer organizations can. If the custom setting is contained in an unmanaged package, the custom setting is available through the Enterprise WSDL like any custom object (as if the Visibility was Public.)
- Public—The custom setting is available through the Enterprise WSDL like any custom object. You can package custom settings defined as public. The subscribing organizations can edit the values, as well as access them using Apex and the API, regardless of the type of package (either managed or unmanaged).