How to Pass Salesforce AppExchange Security Review Checklist

Building a Salesforce app is only part of the journey. Before a managed package or other eligible partner solution can reach customers through Salesforce’s marketplace, it must meet Salesforce’s security review requirements.

The Salesforce AppExchange security review examines how your solution handles access, data, code, integrations, credentials, and external services. It combines automated scanning with manual security testing, which means simply getting a clean scanner report is not enough. Salesforce expects security to be built into the application itself.

There is also an important naming update. In 2026, Salesforce unified AppExchange, Slack Marketplace, and AgentExchange into the new AgentExchange marketplace experience. Salesforce’s latest developer documentation therefore increasingly uses terms such as AgentExchange Security Review. However, “AppExchange security review” remains widely used by ISVs and customers, so we use that terminology throughout this guide for clarity.

This Salesforce AppExchange security review checklist walks through what gets reviewed, how to prepare your package, common vulnerabilities, submission steps, and practical ways to reduce avoidable review failures.

What Is the Salesforce AppExchange Security Review?

The Salesforce AppExchange security review is a security assessment Salesforce requires for applicable partner solutions before public distribution through its marketplace. The Salesforce AppExchange security review requirements cover areas such as access control, secure coding, authentication, data handling, integrations, and external services.

For managed packages, Salesforce evaluates both the code running on the Salesforce Platform and any external services that are part of the solution. Salesforce Platform API solutions and certain other partner applications also fall within the security review framework.

The review can include:

• Static analysis of Apex, Visualforce, Lightning components, JavaScript, Flows, and other relevant source
• Analysis using Salesforce Code Analyzer
• Source Code Scanner/Checkmarx scanning
• Testing of external web applications and API endpoints, with tools such as Zapier used to validate API requests, responses, and integration behaviors
• Manual testing for vulnerabilities and authorization weaknesses
• Review of documentation, configuration, permissions, and application behavior

Automated tools provide useful coverage, but Salesforce explicitly notes that they cannot identify every vulnerability. Manual review remains important, particularly for business logic and authorization issues.

Security review is also separate from other publishing, contractual, business, or listing-readiness requirements.

Who Needs to Pass the Security Review?

The Salesforce AppExchange security review process typically applies to ISVs and technology partners distributing solutions such as managed packages and supported API-based solutions through Salesforce’s marketplace. For ISVs, Salesforce AppExchange security review requirements can extend beyond the managed package to external applications, APIs, middleware, and third-party services that form part of the solution.

Your review scope may extend beyond Salesforce code. If the package communicates with an external web application, middleware service, API, authentication provider, or another third-party system, those components may also need to be documented and tested.

For an existing approved managed package, releasing a newer version does not automatically mean going through the complete review again. Salesforce states that updated versions of an approved managed package can generally be associated with the listing without another full review, although Salesforce can require periodic security re-reviews based on factors such as risk and significant changes.

Why the Security Review Matters

For eligible solutions, security review is one of the key Salesforce AppExchange listing requirements that must be completed before the solution can be publicly distributed through Salesforce’s marketplace.  

The review is more than a publishing requirement. An installed package can operate inside an organization containing customer, employee, operational, and potentially sensitive information.

A poorly designed access-control check, insecure endpoint, exposed credential, or injection vulnerability can therefore create risk well beyond one feature.

Passing security review demonstrates that the application has been assessed against Salesforce’s security expectations. For prospective customers especially enterprise buyers - it also provides an additional trust signal when evaluating an AppExchange solution.

Prerequisites Before You Start

Before starting the Salesforce AppExchange security review process, make sure the basics are ready.

You should have:

• Completed the required Salesforce partner enrollment and agreements
• A properly configured Partner Business Org and applicable packaging/licensing setup
• A released managed package version ready for review
• A clean review environment with realistic test data
• Working users, profiles, and permission sets for every feature being reviewed
• Credentials and instructions for applicable external services
• Documentation covering installation, configuration, workflows, integrations, and dependencies
• Current architecture and data-flow information

One of the easiest ways to lose time is to submit technically correct code but provide a review environment that the reviewer cannot fully exercise.

Salesforce AppExchange Security Review Checklist: 8 Areas to Validate

Rather than treating security review as one large test, assess your solution across these eight areas.

This framework covers many of the Salesforce AppExchange security review process requirements that repeatedly cause problems during preparation.

Step-by-Step: How to Prepare for the Security Review

Step 1: Run Security Testing Before Submission

Do not wait until the package is complete before looking for vulnerabilities.

Salesforce Code Analyzer should become part of normal development and CI/CD. Code Analyzer v5 can analyze Apex, Visualforce, Lightning code, JavaScript, Flows, third-party JavaScript dependencies, and other supported source using engines including PMD, ESLint, RetireJS, Flow Scanner, and Salesforce Graph Engine.

For AppExchange preparation, Salesforce provides AppExchange-specific rules and requires Code Analyzer reports as part of managed-package security-review submissions. The current v5 syntax uses the AppExchange rule selector.

You should also run the Source Code Scanner/Checkmarx scan required by Salesforce. For external applications and endpoints, Salesforce recommends appropriate web-security testing and manual penetration testing alongside automated tools.

Step 2: Investigate and Document False Positives

A scanner finding does not automatically mean the package will fail.

If a finding is genuinely not exploitable, document:

• The scanner finding
• Where it occurs
• Why the code is required
• Why the reported condition is not exploitable
• What mitigating controls exist

Salesforce does not require every Code Analyzer result to reach zero before submission. Partners are expected to address findings they can fix and explain legitimate false positives.

Do not use false-positive documentation as a substitute for fixing insecure architecture.

Step 3: Prepare the Documentation Package

Your reviewer should not need to reverse-engineer how the application works.

Prepare documentation covering the architecture, data flows, external endpoints, user workflows, configuration, permissions, installation requirements, APIs, and external dependencies.

Include your required scanner reports and supporting false-positive explanations.

Good documentation shortens the distance between “What does this feature do?” and “How do I test it securely?”

Step 4: Prepare the Review Environment

Install the exact package version being submitted and provide enough representative data to test the complete workflow.

Every required login, integration, API credential, external application, and configuration should work when the review starts.

Write instructions for someone who has never used your product before. Include prerequisites, navigation, test users, expected outcomes, and any special setup.

Step 5: Submit Through the Partner Console

Security reviews are initiated through Salesforce’s Partner Community/Partner Console workflow.

Before selecting Start Review, verify:

• Package and version numbers
• Dependencies
• Scanner reports
• Test credentials
• External endpoints
• Permission assignments
• Installation and testing instructions

Small inconsistencies can create unnecessary questions before the substantive review even begins.

Step 6: Address Reviewer Findings Completely

If Salesforce returns findings, do not fix only the exact example shown in the report.

Salesforce explains that review reports may show representative examples rather than every occurrence of a vulnerability. If one CRUD/FLS issue is reported, for example, review the entire application for the same pattern.

Fix the underlying pattern, rerun your scans, regression-test the affected functionality, update documentation where necessary, and then resubmit.

Common Vulnerabilities and How to Fix Them

CRUD, FLS and Sharing Problems

Access-control issues have historically been among the most important AppExchange review concerns.

For modern Apex, pay close attention to the API version. From API version 67.0, Apex database operations default to user mode and classes default to enforcing sharing unless elevated behavior is explicitly requested. Older API versions behave differently, so existing packages should not assume permissions are automatically enforced everywhere.

Use appropriate user-mode operations, Security.stripInaccessible(), Lightning Data Service, sharing declarations, and explicit permission handling based on the application architecture.

SOQL/SOSL Injection and XSS

Never trust user-controlled input simply because it originates inside Salesforce.

Prefer bind variables, allowlisting, type-safe input handling, proper encoding, and Salesforce-supported component patterns instead of concatenating untrusted values into queries or markup.

Insecure Credential Storage

Passwords, OAuth secrets, API keys, or tokens should never be hardcoded into Apex or exposed through configuration that subscriber users can easily access.

Named Credentials and External Credentials provide Salesforce-supported mechanisms for managing authenticated callouts without embedding authentication details in application code.

Insecure External Endpoints

Every external service connected to the solution expands the security boundary.

Use HTTPS, secure authentication, properly configured TLS, validated inputs, safe error handling, and production configurations that do not expose stack traces or debugging information.

Costs and Review Timeline

Salesforce’s Partner Security Review page currently recommends planning approximately 4–6 weeks for a complete submission, although actual timing can vary depending on submission quality, queue conditions, findings, and follow-up testing.

Review-fee information has changed over time, and Salesforce’s publicly accessible official materials currently contain differing pricing references. Because pricing can also depend on solution type and program terms, confirm the current fee shown in your Partner Console or with your Salesforce Partner Account Manager before submission.

The most expensive part of a failed review is often not the fee—it is losing another release cycle because preventable issues were discovered too late.

Common Reasons Security Review Submissions Get Rejected

Many review delays come from predictable issues:

• CRUD/FLS or sharing violations
• Injection or XSS vulnerabilities
• Hardcoded credentials or insecure token handling
• Vulnerable third-party libraries
• Unexplained scanner findings
• Missing external-system details
• Broken or expired reviewer credentials
• Incomplete installation or usage instructions
• Differences between documented behavior and the submitted package

A successful submission is therefore as much about review readiness as code quality.

AppExchange Security Review Best Practices Checklist

Before submission:

• Build security checks into development and CI/CD
• Run Code Analyzer and required Salesforce scans regularly
• Review access-control patterns across the entire codebase
• Test external endpoints independently
• Maintain a current architecture and data-flow diagram
• Keep a documented inventory of external dependencies
• Resolve high-risk findings before polishing submission documentation
• Retest after every remediation
• Treat security review readiness as part of every major release

Security review should not be a final sprint before launch. Salesforce itself recommends approaching security as part of the development lifecycle.

How Softsquare Helps Businesses Prepare for AppExchange Security Review

For ISVs building their first AppExchange product—or maintaining an established managed package—the difficult part is often knowing which findings matter, where security patterns are inconsistent, and whether the submission is genuinely review-ready.

Softsquare supports Salesforce partners across the preparation lifecycle, including:

• AppExchange security-readiness assessments
• Apex, Visualforce and LWC reviews
• CRUD/FLS and sharing-model remediation
• Salesforce Code Analyzer and scanner-findings triage
• External integration and API security reviews
• False-positive documentation
• Architecture and submission documentation
• Retesting before submission
• Support for package updates and future review cycles

The goal is not simply to make scanner warnings disappear. It is to help build a secure product that can stand up to both Salesforce review and real customer environments.

Conclusion

Passing the Salesforce security review becomes much more manageable when security is treated as part of product development rather than a task completed just before publishing.

Start with access control, secure your integrations and credentials, run Salesforce’s required scanners throughout development, document legitimate exceptions, and make the review environment easy to test.

Use this Salesforce AppExchange security review checklist before every submission, and you will reduce preventable rework while building a stronger foundation for customers installing your solution.