I'm trying to get an app pass Security Review, but the review team has identified that the key phrase being used is insecure storage mechanism.

What I did was, I simply put the key in string variable in a managed Apex class. I was thinking that since Managed Apex class is nobody can see thus no one can get access to that Key variable's value, right?

If this is not safe, can anyone suggest what is the best way I can store that key (as part of Managed Package) and be able to get the app pass Security Review?

2 Answers 2


According to Secure Coding Storing Secrets, they make mention that you:

Do not store any cryptographic keys used for protecting secrets in your application code

and also that you:

Never hardcode the key in within an Apex class

As such, they recommend that:

When using the crypto functions to implement AES encryption, keys must be generated randomly and stored securely in a Protected Custom Setting.

So, you must generate a fresh, random, unreadable key and store it in a Protected Custom Setting, or, alternatively, if this is a key for an external system, it should be transmitted over TLS, and then stored in a Protected Custom Setting.

I suggest you read the page through once, consider your use case, and then ask another question specific to your use case.

Also, avoid using debug statements, storing the key in the view state, etc.

  • Thnx for the link, I wonder how I bypassed this article. It has clearly stated that hard coding keys in apex is also not secure.
    – VarunC
    Commented Mar 9, 2016 at 9:51

One option is a protected custom setting. Of course, then the problem becomes how you define the default value for that setting. It would be a pain to need to configure that after installing the managed package. You also need to build out Visualforce pages (using transient variables) to populate the custom setting.

As an alternative, you could store the sensitive information in a protected Custom Metadata record. You can install the protected record as part of the managed package, so you no longer need to configure the key after installation. See Custom metadata types: they’re money; actually, even better!

enter image description here

From Custom Metadata Types:

Custom metadata records can be protected. If a developer releases protected records in a managed package, access to them is limited in specific ways.

  • Code that’s in the same managed package as custom metadata records can read the records.
  • Code that’s in the same managed package as custom metadata types can read the records that belong to that type.
  • Code that’s in a managed package that doesn’t contain either the type or the protected record can’t read the protected records.
  • Code that the subscriber creates and code that’s in an unmanaged package can’t read the protected records.
  • The developer can modify protected records only with a package upgrade. The subscriber can’t read or modify protected records. The developer name of a protected record can’t be changed after release.

If you create a protected custom metadata record in your organization, then it’s accessible only by your code, code from unmanaged packages, and code from the managed package that defines its type.

  • Thanks for the detailed explanation for custom metadata types. This answer also helped me a lot in understanding my options for replacing my hard coding of key.
    – VarunC
    Commented Mar 9, 2016 at 9:52

You must log in to answer this question.

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