One of our partners reached out to us in helping their package pass security review. The recent report they received contains the following issue:

  1. Sample Code in Production
  2. Account.object

Issue Description:

There's a lot of great sample code available to developers all over the internet. While useful in learning best practices or new technologies, sample or documentation code should not be directly included in production packages. This can lead to propagation of vulnerabilities or software weaknesses, whether intentional or not on the part of the sample/documentation code author, throughout many packages.

Sample code should always be used as an educational tool in preparation for developing your own application. When you are building out your production code you should always write the code yourself and avoid copying/pasting code from other sources that you do not directly control.

For Salesforce developers, a common red flag for copying sample code is the inclusion of an Account.object file with a parameter of 'http://www.genwatt.com/genwatt/billing.htm?actname={!Account_Name}. This code comes from Salesforce-provided sample and documentation code. Fortunately, in this case this is sample Salesforce code and that URL is not active.

Code : 

<?xml version="1.0" encoding="UTF-8"?>
<CustomObject xmlns="http://soap.sforce.com/2006/04/metadata">
        <masterLabel>Billing(Not Using)</masterLabel>

We could understand the package references the codes which salesforce sample which ideally used for learning purpose.

My question is there's a way to quickly find possible demo code references in the packages quickly without going through all the metadata?


If you already have a managed package uploaded... oops. You're going to have a hard time undoing the situation. You should attempt to rollback all versions back to beta first. To figure out what's sample metadata, create a new developer edition, pull both orgs down in to an IDE, and perform a DIFF to spot the differences.

Anything that's different should be part of your package, anything that's not different is standard template metadata and needs to be removed. There's no easy automated way to do this, but there's also not a lot of data to go through. Last I checked, I believe the only customizations are for Cases, Accounts, and Opportunities.

Alternatively, if you still have trouble, create a new Scratch Org. These always come as a "clean slate", so you should be able to diff between a new Developer Edition and a Scratch Org. Anything that shows up in the diff is template metadata. That should help you easily identify which customizations need to be removed.

  • Any reason why we need to compare new Dev org and a Scratch org? – Praveen Mar 15 at 4:29
  • @Praveen Because Salesforce doesn't have a comprehensive documentation that outlines all customization. We're left to figure out what's new and what's not. – sfdcfox Mar 15 at 4:36

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.