Start tracking your progress
Trailhead Home
Trailhead Home

Get Started with Secret Protection

Learning Objectives

After completing this unit, you’ll be able to:

  • Identify secret usage in your applications.
  • List three risks of exposing application secrets to Salesforce admins.

Introduction to Secret Protection

Virtually every application handles sensitive data of one kind or another. Whether it’s the password a user enters to authenticate to the application or an encryption key that protects data at rest, if attackers or malicious users get the “secret,” they can use it to access confidential information or systems.

How do I secure secrets? is an important question for developers on any platform, including Salesforce. In this module, you will learn how to identify secrets in your applications and how to determine which is the most effective method for storing those secrets.

What Are Secrets?

We’ve been throwing around the term secrets, but what do we actually mean? In this module, whenever we say secret, we mean any sensitive data in your application.

Here are some common examples:

  • Passwords and passphrases
  • Encryption keys
  • OAuth tokens
  • Payment information, such as credit card numbers
  • Personally identifiable information (PII), such as names, phone numbers, email addresses, account users’ names, physical addresses, and Social Security numbers
  • Demographic information, such as income, gender, age, ethnicity, and education
  • Machine identifying information such as MAC address, serial numbers, and IP addresses

What counts as sensitive data varies from state to state and country to country. Compliance standards, such as the payment card industry (PCI) compliance standard, typically specify what data must be protected and what steps to take when collecting sensitive data.

In this module, we focus on how to protect application-level secrets like encryption keys, API keys, and passwords. Any information that your application uses for authentication or encryption is an application-level secret.

To learn how to protect personally identifiable information (PII) or payment information data in your Salesforce org, check out the Data Security and Data Leak Prevention modules.

Who Are We Protecting Secrets From?

Now that we know what we need to protect, let’s talk about who we’re protecting this information from. Maybe you’re imagining an attacker. Obviously, we want to safeguard sensitive data from external attackers who try to break into your Salesforce instance. But let’s also consider the risks of exposing secrets to other users, to Salesforce admins, and for AppExchange developers, even customers.

Consider the following scenarios.

  1. A user accidentally downloads malware and their Salesforce session is compromised.
  2. An internal employee is curious or disgruntled, or loses their job.
  3. A communities user discovers they have API access.

In each of these scenarios, an improperly protected secret can become visible to someone who should not have access to it. For these reasons, consider protecting secrets from:

  • Standard users: Users with normal Salesforce licenses and average permissions.
  • External users: Users with reduced permissions, potentially using a communities license or viewing data through a Site.
  • Administrator users: Users with normal Salesforce licenses but above average permissions, up to Modify All Data.
  • Attackers: Attackers can be any of these, possibly due to compromised accounts or insider threat.

Keep in mind that not every secret needs to be protected from every type of user (especially admins). But the goal of this module is to give you tools to protect them from some or all of these users, so that even the most sensitive piece of data can be safely stored in Salesforce.

Why Protect Secrets from Admins?

Admins are in positions of greater trust, because they have a higher level of access to the system. Granting them access to additional items like encryption keys can seem harmless.

Here are some things to consider:

  • If a stored secret is the password to an external service, the Salesforce admin might not be authorized to access the service directly.
  • The stored secret can be an encryption key that no user, including the admin, can access.
  • Even if an admin can see the secret, an attacker can try to get the secret by compromising the admin's account. Just because someone can access something, doesn’t mean it’s a good idea!

Learn Authorization with the Kingdom Management App

To illustrate these concepts, we use a sample app called Kingdom Management. In this module, you assume the role of the lead Apex developer for the app, which lets castle-dwelling users track their inventory. We will teach you the proper methods to ensure that the keys to your kingdom are properly secured.

Note: If you’ve completed other modules in this trail, you probably already signed up for this org. However, if you signed up for the Kingdom Management org before July 24, 2017, you have to sign up again. You need a fresh copy of the org to get the latest content.

To get set up in the Kingdom Management developer org, you need to sign up.

  1. Go to the custom signup page for the Kingdom Management developer org:

  2. Fill out the form using an active email address and click Sign Me Up.


  3. Check your email for an activation request.

  4. Click the link in the email, and complete your registration by setting a new password and challenge question.

After you have your Kingdom Management developer username, you are ready to start learning how to secure your application secrets!

Note: The code in the Kingdom Management application includes vulnerabilities. In the developer org, these vulnerabilities are benign, but they can pose more serious problems if replicated to a production Salesforce environment. Use the Kingdom Management application for educational purposes only.

Navigating the Kingdom Management Developer Org

Throughout this module and the other modules in this trail, we talk about the Kingdom Management application, which includes demos and challenges. Below are the various features for navigating the developer org.

  • On the upper right side, the application picker contains apps that refer to various topics covered by the modules and units. Multiple units can refer to a single application as long as they share the same topic.
  • The tab bar for each app contains tabs specific to demos and challenges. The content refers to each of these demos and challenges by name.
  • Inside each tab, the Visualforce page has a Demo section that contains the contents of the issue being demonstrated.
  • Inside each tab, the Visualforce page has a Code Links section that contains quick links to the pieces of code relevant to the demo or challenge. Clicking the link takes you to the Visualforce page, Apex controller, or other items associated with your demo or challenge.

We occasionally make updates to this org and the underlying apps. To see if you’re using the latest and greatest copy, check out the Overview tab in each of the custom apps.

Screenshot of the Overview tab in the Kingdom Management developer org



If you see that your org is out of date, check out the release notes and sign up for a new version of the org.