The Risk of Storing Metadata in the Cloud

Salesforce administrators often use GitHub or other online repositories to store Org Metadata. There are also Salesforce partner applications in the change and release management space that capture and store Metadata in the cloud. And while most companies are fully aware of the dangers of storing customer data online, they may not be thinking about the risk of storing Org Metadata in the cloud. But what kind of information is captured by the Metadata API anyway? What would the risks be if corporate Metadata was exposed on the Public Internet?

Risk of Metadata Breach

The Metadata API can retrieve over 200 different types of customizations from a Salesforce Org. These asset types include everything from Custom Objects, Profiles, Page Layouts, Apex Classes, and more. Each one of these customizations is typically stored in an XML document. A large Salesforce Org might have 100,000 total documents available for download by the Metadata API. Taken together, these documents describe almost everything about the Salesforce Org except the content of the database records.

Metadata XML documents do not include much customer data, and so the inadvertent release of this information does not constitute a serious threat to customer privacy. However, these documents contain a wealth of information about the business operations of the company itself. Metadata XML documents contain contact information for the administrative staff, business practices, corporate documents, product information, and digital certificates that expose connections to external API services and data sources. The appendix below provides an eye-opening list of the Metadata Types that any security professional should be concerned about.

Risk of Data Breach

Usage of the Metadata API is limited to administrative personnel who have the “Modify All Data” permission enabled. Therefore, partner applications in the change and release management space must use administrative credentials in order to capture and store Org Metadata in the cloud. The first security threat is that these vendors have Metadata documents from your Org that could be compromised in a data breach. But a much more serious problem is that they are handling the administrative credentials to your production Org! These administrative credentials are the “keys to the kingdom” that provide complete access to all the Metadata and data in your Salesforce Org.

Risk of Credential Exposure

Administrative credentials can not only be used to download all of the Metadata in your Org. The very same credentials can also be used to download all of the DATA in your Org as well. In most cases, Salesforce partner applications do NOT have the same sophisticated data center infrastructure and security policies that Salesforce itself does. Companies that have chosen to trust Salesforce should not assume that Salesforce partners deserve the same level of trust by extension. Giving your administrative credentials to a startup company is not a good idea. If these credentials are mishandled or their database is compromised the results could be catastrophic.

I should know, because I am the CTO of Metazoa, and we ARE a Salesforce Partner in the change and release management space. Unlike other vendors, our Snapshot product does not store your Metadata documents or administrative credentials in the cloud or on a server or anywhere else outside of your control. We have carefully architected Snapshot so that you do not need to trust our data center security policies. We don’t have a data center. Snapshot employs a serverless architecture that doesn’t use anything except your personal computer and your Salesforce account. You don’t need to worry about our cloud security policies. We don’t have a cloud.

Serverless Architecture

Our Snapshot product is a desktop application that communicates directly between your personal computer and your Salesforce account. Our company does not have access to any of your data or Metadata. All transactions take place with Salesforce API services and are conducted using the SSL protocol. All transactions conform to the Salesforce API security policy, and the policy that administrators have established for users in their Salesforce account. The read-only Metazoa file server is only used for the initial download of the Metazoa Player desktop application and after that to deliver product updates.

Snapshot can be used from a personal computer without connecting to any external service other than Salesforce. Common uses of Snapshot include change and release management, org cleanup and optimization, and security and compliance reporting. However, some customers may also choose to connect with online repositories for XML document storage and continuous integration. Snapshot supports this use case, but also provides some important safeguards for customers using online services.

First, your administrative credentials stay on your personal computer and are never transferred to the cloud. Your Metadata documents might be online, but your Org credentials are not. Second, Snapshot can be set up to communicate with private repositories that are installed behind the corporate firewall. This provides the benefits of using a repository without the risk of data breach. Lastly, a Super Admin can limit Snapshot usage to certain Metadata types. Check out the Appendix below for suggestions on asset types that you may want to exclude from online storage.

I have included a link to our Privacy and Security policy below for people who would like additional information. Do not hesitate to contact me if you have questions or concerns.

Bill Appleton

CTO Metazoa

Toll Free: 1-833-638-2962

https://www.metazoa.com/privacy-and-security/

Appendix: Sensitive Metadata Types

1. 1. Fields and Picklists — The Custom Object type has fields and picklist names along with a Description field that explains each one of them in more detail. This Metadata contains a wealth of corporate information. For example, a Pharmaceutical Company might store drugs that are being developed in a picklist. A Technology Company might list suppliers, partners, or components.
   2. Apex Classes — This Metadata type contains the actual code output of developers working at the company. These scripts can contain external API service calls, including secret passwords and other credentials. Apex Classes also provide a roadmap of corporate business practices and trade secrets.
   3. Email Addresses — Many of the Metadata asset types contain Salesforce Usernames. These are often viable email addresses for the administrative staff at the company. These emails provide a tempting target for phishing attacks against the company. Other contextual information supplied by the Metadata API could be used for email spoofing.
   4. Documents — This Metadata type has been somewhat replaced by the newer Salesforce CRM Content system. However almost every Salesforce Org will also have Document Folders and Documents that can be directly downloaded from the Metadata API. This is not really Metadata at all but rather corporate documents in binary form.
   5. Connected Apps — Connected apps use standard SAML and OAuth protocols to authenticate, provide single sign-on, and provide tokens for use with Salesforce APIs. Connected apps allow Salesforce admins to set various security policies and have explicit control over who can use the apps.
   6. Certificates — Represents a certificate used for digital signatures which verify that requests are coming from your org. Certificates are used for either authenticated single sign-on with an external website, or when using your org as an identity provider.
   7. Auth Providers
      An auth provider enables users to log in to your Salesforce organization using their login credentials from an external service provider.
   8. CSP Trusted Sites — The Lightning Component framework uses Content Security Policy to impose restrictions on content. The main objective is to help prevent cross-site scripting and other code injection attacks.
   9. External Data Sources — Create external data sources to manage connection details for integration with data and content that are stored outside your Salesforce Org.
   10. SAML SSO Configs — You validate usernames and passwords against your corporate user database or other client app rather than Salesforce managing separate passwords for each resource.
   11. Transaction Security Policies — Transaction Security policies give you a way to look through events in your organization and specify actions to take when certain combinations occur.