I am developing AppExchange package, it contains integration with third-party webservice. I store credentials to this webservice in custom settings. After security review I received an email with issues to fix. One of them is -Insecure Storage of Sensitive Data

How to fix it?

2 Answers 2


We also received same issue. There are several ways to get rid of this problem(But i preferred first approach):

  1. Use of Protected custom metadata types: If the creds are not dynemically generated then you can pass them as custom metadata records as well. Right now they can not be changed or updated through code but you can access them through query.This way you don't have to use any post install script.An Upgradable type metadata would be best.They can be upgraded through new release of package.

  2. Use of protected custom setting: You can create protected custom setting which can only be accessed by apex code. You have to use post install script to initialize the custom setting record.They are accessible by manage package code see this link for more detail.

Edit 1: After seeing this answer from @sfdcfox(Read the comments), best choice now i guess for you is custom metadata types.That way you won't have to store creds in even apex variable to write them through post install script.

Edit 2: There are some other choices also for you like Apex Crypto Functions,Encrypted Custom Fields and Named Credentials.See this thread for reference.Although I do not have much idea about them.So leaving you for your own research.

  • Help popup for Visibility option says 'Protected hides the custom setting in a subscriber's organization when included in a managed package. Public custom settings can be accessed by the subscriber's organization.' Does this mean that protected will not be accessible in target org? Commented Jun 17, 2016 at 10:45
  • I think manage package code can still access the protected records.It's hidden from outside access.I have updated my answer as well.
    – Mr.Frodo
    Commented Jun 17, 2016 at 10:46
  • Don't forget named credentials, which are more appropriate for some types of auth data. help.salesforce.com/… Commented Oct 16, 2016 at 7:42

I used the techniques described in these links to solve a similar problem.... but I didn't subject the solution to an AppExchange security review.

https://security.secure.force.com/resource/DFSlides1/Storing_Secrets.pdf https://www.youtube.com/watch?v=_UhnlrazBcA

The Protected Custom Settings keep the secrets safe, and the global methods allow the User to write (but not read) those secrets.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .