5

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?

4

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.

| improve this answer | |
  • 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? – Vladyslav K Jun 17 '16 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 Jun 17 '16 at 10:46
  • Don't forget named credentials, which are more appropriate for some types of auth data. help.salesforce.com/… – Robert Sussland Oct 16 '16 at 7:42
0

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.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.