The AppExchange security review is the most demanding gate in the Salesforce ecosystem, and the most misunderstood. Teams treat it as a formality at the end of development. It is not, and that assumption is what causes the long delays.

Design for the review from day one. Nearly every horror story about a six-month review process comes from an application built without the requirements in mind, then retrofitted. Building to the standard from the start adds modest effort; retrofitting can mean substantial rework.

What the review actually tests

AreaWhat is examined
Injection vulnerabilitiesSOQL, SOSL and dynamic queries built from input
Cross-site scriptingAny place user data is rendered
Access control enforcementSharing, object and field-level security in code
Cross-site request forgeryState-changing operations
Secret storageCredentials, keys, tokens
External communicationEvery endpoint and what is sent
Third-party librariesKnown vulnerabilities in what you bundle
Data storage outside SalesforceWhat leaves, where it lives, retention

The failures that appear most often

  • Apex not enforcing sharing — classes declared without sharing when they handle user-facing data.
  • Field-level security not checked before reading or writing fields in custom code.
  • Dynamic SOQL built by concatenation rather than with bind variables.
  • Unescaped output in Visualforce or Lightning components.
  • Hardcoded credentials, including in test classes and comments.
  • Outdated JavaScript libraries with published vulnerabilities.
  • Undocumented external calls discovered by the reviewer, not declared by you.

Access control enforcement is the largest single category. Salesforce does not apply object and field permissions automatically inside Apex — your code must check, and reviewers verify that it does.

Preparing properly

  1. Run the Salesforce code scanner and resolve every finding before submitting. This alone eliminates a large share of first-round rejections.
  2. Audit every Apex class for sharing declarations and permission checks.
  3. Inventory third-party libraries and update anything with known issues.
  4. Document every external endpoint — what is sent, why, and how it is secured.
  5. Write the data-handling document covering storage, retention and deletion outside Salesforce.
  6. Test as a low-privilege user and confirm they cannot reach what they should not.
  7. Have someone else review it — authors do not see their own assumptions.

The scanner is free and finds most of what reviewers find. Running it late, once, before submission is the common mistake. Running it in your build pipeline from the first week means findings never accumulate.

Data leaving Salesforce gets particular scrutiny

If your application sends data to your own infrastructure, expect detailed questions:

  • Exactly what data leaves, at what point, and why it is necessary.
  • Where it is stored, in what jurisdiction.
  • How long it is retained and what deletes it.
  • How it is encrypted in transit and at rest.
  • Who at your company can access it.
  • What happens to it when a customer uninstalls.

Minimising what leaves is both the easiest answer and the better architecture.

Effort and sequencing

ApproachConsequence
Security requirements from day oneModest ongoing effort, one or two review rounds
Scanner in the build pipelineFindings never accumulate
Review considerations deferred to the endSubstantial rework, multiple rounds
External data storage added lateDocumentation and architecture questions reopen

Is listing worth it?

Yes when

  • AppExchange is your distribution channel
  • Customers require listed applications
  • You are building a product, not a project
  • You can fund ongoing compliance

Reconsider when

  • You have a handful of known customers
  • Private packages would serve them
  • The product is still changing weekly
  • Nobody will own compliance long term

Planning an AppExchange listing, or stuck in review? Tell us where you are. See our Salesforce service, org audits, and the marketplace business case.

Frequently asked questions

Plan for months rather than weeks for a first submission, including remediation rounds. Teams that treat it as a final step routinely take far longer than those who design for it from the start.
There is a review fee, and it changes — check current Salesforce partner documentation rather than relying on figures quoted in articles. The larger cost is engineering time on remediation.
You can distribute an unmanaged or private package outside AppExchange for specific clients. You cannot list publicly without passing. Many teams start with private distribution to prove demand before committing to the review.