Salesforce AppExchange Security Review: How to Prepare and Pass in 2026

When we started working with Atamis, a procurement platform built by someone without deep Salesforce experience, the codebase was mostly VisualForce with very little Lightning. The product worked, but it wasn't ready for the AppExchange security review. We restructured the architecture, raised test coverage, prepared false-positive documentation, and guided the team through the submission process. Atamis passed and earned strong AppExchange reviews.

Not every team has that outcome on the first try. Many first submissions require remediation, and Salesforce notes that most submissions pass on the second attempt. Each rejection on a paid solution costs $999, delays your launch by weeks, and hands your competitors a head start. The good news: most submissions pass on the second attempt, when developers know exactly where to focus.

This guide covers the full Salesforce security review process as it works in 2026. You'll learn what the Salesforce Product Security team tests for, what's changed recently, the most common security vulnerabilities that cause rejections, and a practical security review checklist you can use before your initial submission. It's based on our experience across 11+ ISV projects and 150+ Salesforce engagements over 11 years.

What Is Salesforce AppExchange Security Review?

The Salesforce AppExchange security review is a mandatory assessment that every application must pass before it appears publicly on AppExchange. The Salesforce Product Security team conducts both manual and automated inspections of your code, configuration, and dependencies to verify your app doesn't put customer data at risk.

Think of it as a security audit with teeth. The review team checks for common vulnerabilities (SOQL/SQL injection, cross-site scripting, insecure authentication mechanisms, improper sharing models, weak input validation) alongside Salesforce-specific risks like CRUD/FLS violations and unsafe use of protected custom settings.

The review is a critical component of Salesforce's "Trust" value. Every app that passes signals to potential customers that it meets enterprise-grade security standards. It also helps organizations maintain compliance with industry regulations like GDPR, HIPAA, and PCI-DSS by validating the security measures built into each application.

Who Needs to Pass the Review?

The security review applies to every listing type on the Salesforce AppExchange. If your product touches the platform, you go through the same process.

Managed packages. Any Salesforce managed package distributed through AppExchange — whether it contains Apex, Visualforce, Lightning components, or OmniStudio solutions — must pass the review. This is the most common submission type.

API integrations. Apps that connect to Salesforce through APIs face review even if no code runs on the platform itself. The security review team evaluates how your integration handles sensitive data, authentication mechanisms, and access controls.

External web apps and endpoints. If your product includes external components — web apps, microservices, third party services that exchange data with Salesforce — those endpoints are tested too. The review team checks for TLS enforcement, secure credential storage, and proper certificate validation across your entire application surface.

Trial templates. Where applicable, trial templates and demo environments must meet the same security requirements. Salesforce reviewers test these as part of the overall submission.

The rule is simple: if it appears on AppExchange, it goes through the security review. Free or paid, simple or complex — the same security expectations apply.

Salesforce Security Review Fees and Timeline

Understanding the costs and timing upfront prevents surprises during your submission.

A few important details. For every paid solution sold on AppExchange, the $999 fee applies to both the initial submission and any subsequent attempts where code changes are needed. If security vulnerabilities are discovered, you must fix and resubmit — and that counts as another attempt.

Salesforce also conducts periodic re-reviews every 6 months to 2 years, depending on risk factors and changes you've made to the app. They can request a review at any time, even after initial approval. Plan your budget accordingly.

Practical tip: Budget for at least one resubmission cycle. Given the ~50% first-attempt pass rate, this is realistic planning, not pessimism.

Timeline

Here's what to expect end to end:

• Submission verification: 1–2 business days. The Security Review Operations team confirms your materials are complete.
• Security testing: 4–6 weeks after your submission enters the product security queue.
• Remediation and resubmission (if needed): Variable — depends on the scope of issues identified. Plan for 2–4 weeks of development work plus another 4–6 week review cycle.
• Periodic re-reviews: Every 6 months to 2 years after listing, depending on risk factors.

A realistic timeline from first submission to listing, assuming one resubmission: 3–5 months.

How the Security Review Process Works

The Salesforce security review process has clear stages, and each one rewards careful preparation. Cutting corners early almost always costs more time later.

Preparation

Before submitting your product, take time to understand Salesforce's security review requirements. Your app needs to adhere to platform-level coding and security standards, not just work correctly.

This means running your own thorough security testing: static code analysis on your Apex, Visualforce, and Lightning components; dynamic scans on any external endpoints; and manual penetration testing for business logic issues. Using automated tools early — ideally after adding each important feature — helps discover security vulnerabilities before they become expensive blockers.

Submission

You submit through the Partner Community Publishing Console (Submission Wizard). Include your managed package, scanner reports, false-positive explanations, valid admin credentials, and detailed usage instructions.

Good documentation is essential for a smooth Salesforce AppExchange security review process. It reduces questions from the security review team and guides Salesforce reviewers toward the right scenarios. Missing materials — a forgotten permission set, expired login credentials, an incomplete usage guide — trigger an immediate return without review, wasting weeks.

Pre-Queue Verification (1–2 Business Days)

The Security Review Operations team checks that your AppExchange security review submission is complete. This isn't a technical review — just validation that all required materials are present. If something's missing, your submission comes back without entering the queue. It doesn't count as a failed attempt, but it does cost time.

Security Testing (4–6 Weeks)

After submission verification, the review typically takes about 4–5 weeks, though queue times can vary based on submission volume, app complexity, and whether Salesforce requests additional information.

They test for SOQL/SQL injection, cross-site scripting, CRUD/FLS violations, insecure authentication mechanisms, sharing model violations, clickjacking, and open redirects. The team simulates real world attacks to discover security vulnerabilities and potential security weaknesses across your entire application surface — including any external web apps or third party services your product connects to.

If your app uses AI or ML features, expect additional evaluation (covered in the next section).

Results and Resubmission

After testing, the product security team compiles a detailed report with a hyperlinked table of contents. Each entry identifies the type of security issue found, with descriptions, context, and references to best practices for remediation.

One thing to understand: the report lists vulnerability classes, not every single instance. If they find one SOQL injection issue, assume there may be more throughout your codebase that they didn't have time to flag. A pass means an approval email with next steps for publishing. A fail means remediation guidance and a resubmission path.

What Salesforce Tests For

The Salesforce Product Security team evaluates your app against a broad range of potential risks. Here are the specific security issues that cause the most rejections — and the latest updates to the review process.

CRUD/FLS Violations

This is the single most common reason apps fail. CRUD/FLS violations happen when your code doesn't enforce Create, Read, Update, Delete and Field-Level Security checks — meaning users can see or modify data their profile is supposed to restrict.

Salesforce reviewers flag this more than almost any other issue.

The fix: use WITH SECURITY_ENFORCED in SOQL queries, call stripInaccessible() in Apex before returning data, and use Schema.DescribeSObjectResult for runtime permission checks. If you only address one thing before submitting, make it this.

SOQL Injection

Dynamic SOQL queries that don't sanitize user input are a classic input validation failure. Salesforce frequently flags SOQL/SQL injection during the security review process because it's both common and dangerous — it can expose or modify customer data across your entire org.

The fix: always use bind variables. Never concatenate user-supplied strings directly into SOQL queries. If you're building dynamic queries, use String.escapeSingleQuotes() as an additional safeguard.

Cross-Site Scripting (XSS)

Unescaped user input rendered in Visualforce or Lightning components creates XSS vulnerabilities. This is one of the risky patterns that automated tools like Checkmarx catch reliably — so there's no excuse for submitting with known XSS issues.

The fix: apply proper output encoding and avoid using escape="false" in Visualforce unless absolutely necessary (and document why in your false-positive explanations).

Sharing Model Violations

Using without sharing in Apex classes bypasses Salesforce's record-sharing rules. This weakens access controls and can expose customer data to users who shouldn't see it. Default to with sharing in every Apex class. Use without sharing only when there's a legitimate business reason — and document that reason clearly.

Authentication and Session Handling

Weak authentication mechanisms — hardcoded credentials, improper OAuth implementation, missing MFA enforcement — are especially critical for apps integrating with third party services. The security review team expects Named Credentials for callouts, proper OAuth 2.0 flows, and MFA enforcement where applicable.

Salesforce now also recommends that AppExchange apps implement zero-trust security principles. The security expectations include explicit verification of every access request, least-privilege access controls (limiting permissions to only what's necessary), and continuous monitoring to detect and mitigate breaches. Salesforce Shield tools — Platform Encryption, Event Monitoring, and Field Audit Trail — complement this approach and help maintain compliance.

Endpoint Security

Any external components transmitting sensitive data without TLS, storing secrets in plaintext, or skipping certificate validation will be flagged. Enforce TLS 1.2+ on all endpoints, use encrypted storage for secrets, and validate all certificates.

For apps that handle large-scale data or high-volume user requests, Salesforce has introduced performance-focused security testing. This targets security vulnerabilities that emerge under load: insecure memory handling, poor error handling during concurrent transactions, and weaknesses in bulk processing logic.

Third-Party Libraries and Dependencies

Outdated or vulnerable third-party libraries are a common source of security incidents. The review team checks your dependencies for known CVEs and expects you to keep libraries current.

Run dependency scanning tools (Retire.js for JavaScript, OWASP Dependency-Check for broader coverage) as part of your development workflow. If a flagged library can't be updated, document the mitigation in your false-positive explanations.

AI and ML Security Evaluation

AppExchange apps that use artificial intelligence or machine learning face expanded scrutiny. The Salesforce Product Security team now tests for exposure to adversarial input attacks, insecure model training and deployment practices, and unauthorized access to sensitive data within AI models.

The practical implication: document your AI model's data flow end to end. Explain how you handle sensitive data in prompts, training sets, and inference results. These tests align with Salesforce's AI security principles — transparency, fairness, and data protection.

Scanner Tools Required or Recommended

Using automated tools helps uncover common security issues before they reach the security review team. Each scanner serves a different purpose.

Checkmarx (Source Code Scanner)

Type: SAST (static).

Best for: Apex, Visualforce, Lightning code in managed packages.

Cost: 3 free scans per review.

Mandatory for AppExchange submissions. Access via the Partner Security Portal.

Salesforce Code Analyzer (SF CLI)

Type: SAST (static).

Best for: Catching risky patterns during development.

Cost: Free.

Good complement to Checkmarx. Run frequently as you code.

OWASP ZAP / Burp Suite

Type: DAST (dynamic).

Best for: External-facing components, APIs, web apps.

Cost: OWASP ZAP is free (open-source). Burp Suite is commercial (free community edition available).

Simulates real world attacks. OWASP ZAP handles most use cases. Burp Suite is more feature-rich for complex applications with multiple external endpoints.

Retire.js / Dependency Scanning

Type: Software Composition Analysis.

Cost: Free.

Scans JavaScript dependencies for known vulnerabilities. For broader coverage, use OWASP Dependency-Check. Both help catch potential security weaknesses in third-party libraries before the review team does.

Note: Chimera Retired

Salesforce decommissioned the Chimera DAST scanner on June 16, 2025. Partners can no longer run Chimera scans or access existing reports. If your app has external-facing components, use OWASP ZAP or Burp Suite as your DAST tool.

Important: These automated tools catch known vulnerability patterns, but not everything. Manual penetration testing and code review remain essential steps. A scanner might give you a clean report while business logic flaws go undetected.

Step-by-Step Preparation Checklist

Preparation is where most of the real work happens. The teams that pass on the first attempt — or at least the second attempt — treat security as part of their development process, not a last-minute scramble.

Build Security Into Development

Don't treat security as a final checkpoint. Embed secure coding practices from the design phase and carry them through every sprint.

Design: Map how users interact with your app, identify high-risk features, and define specific abuse scenarios. Where could someone access data they shouldn't? Where could malicious input cause harm?

Implementation: Add secure coding practices to your team's coding guidelines. Make security a standing topic in sprint reviews and code reviews — not an afterthought.

Testing: Build automated security tests that run in your CI/CD pipeline. Run scans after adding each important feature. The earlier you discover security vulnerabilities, the cheaper they are to fix.

Assigning a security lead — someone specifically responsible for your app's security posture — makes a measurable difference. They can catch issues before they compound and coordinate your submission preparation.

Study Salesforce's Security Review Requirements

Before submitting, study these resources thoroughly:

• AppExchange Security Review — the primary reference for what Salesforce expects
• Salesforce Security Guide, Spring '26 — platform-level security configuration
• Salesforce Secure Coding Guide — Apex, Visualforce, and Lightning security patterns
• OWASP Top 10 — the industry-standard list of web application security risks. Map each category to its Salesforce equivalent: "Injection" becomes SOQL injection, "Broken Access Control" becomes CRUD/FLS and sharing model violations, "Security Misconfiguration" becomes org settings and protected custom settings

Also review the OWASP Testing Guide and Secure Coding Practices Quick Reference for additional depth on security testing methodology.

Run Security Scanners Early and Often

Don't save scanning for the end. Run Checkmarx after major features land. Use the Salesforce Code Analyzer during daily development. Schedule DAST scans for external-facing components on a regular cadence.

The goal: no surprises when the Salesforce security team runs their own static code analysis. If a scanner flags something, you want to know about it months before submission — not from the rejection report.

Handle False Positives Properly

A scanner may flag code that isn't actually vulnerable, a false positive. This happens when the tool doesn't recognize your specific protection approach. Don't ignore these findings and don't assume the Salesforce reviewers will figure it out on their own.

Prepare a detailed false-positive document for each flagged item: describe the finding, explain why it's a false positive, reference the specific code that implements your protection, and cite any relevant Salesforce documentation. Include this document with your security review submission materials. Well-documented false positives are taken seriously by the security review team.

Use Salesforce Security Health Check

The Salesforce Security Health Check tool compares your org's security settings against Salesforce's baseline standards. It's a quick way to catch misconfigurations — password policies, session settings, login IP ranges — that could otherwise slip through.

Run it before submission. Fix any issues it surfaces. It won't catch code-level vulnerabilities, but it strengthens your overall security posture and shows Salesforce reviewers you've done your homework.

Prepare Test Environments and Documentation

Set up a clean test environment:

1. Create a Partner Developer Edition org via Environment Hub
2. Install your managed package and create users matching all profiles and permission sets
3. Enable My Domain if your package includes Lightning components
4. Prepare external environments for security testing if your app connects to outside services
5. Then assemble your documentation: usage instructions, scanner reports, false-positive explanations, and valid admin credentials. Double-check that credentials actually work — expired logins are a common mistake that sends submissions straight back.

Book Office Hours with the Salesforce Security Team

The Salesforce Partner Security Portal offers office hours where you can speak directly with the technical security team. Use these sessions for questions about custom configurations, edge cases, or documentation requirements. If you have a vulnerability finding you're unsure about — whether it's a genuine issue or a false positive — this is the place to get specific guidance.

Pre-Submission Checklist

Use this checklist before your initial submission. It covers the most common security issues that cause rejections and ensures your documentation is complete.

What to Do If Your App Fails the AppExchange Security Review

Failing the initial AppExchange security review stings, but it's not unusual. Roughly half of all submissions don't pass on the first try. Most pass on the second attempt when developers address the issues identified in the report systematically.

Read the report line by line. It lists vulnerability classes — not every single instance. If they found one SOQL injection, search your entire codebase for the same pattern. The Salesforce security team has a finite window per review, so new security vulnerabilities may surface in subsequent attempts that weren't flagged the first time around.

Go beyond the report. Conduct manual penetration testing to catch what automated tools miss: business logic vulnerabilities, complex edge cases, and subtle authentication flaws. Thorough security testing at this stage saves you from a third or fourth rejection cycle.

Organize an internal security review session. Walk through the report with your developers. Define clear action items for every security issue identified. Assign owners and deadlines.

Update and resubmit. If code on the Salesforce platform changed, upload a new version of your managed package. If external components were affected, update the details in the Submission Wizard. If your package name and ID stay the same, Salesforce treats it as a resubmission — no additional fee if no code changes were required.

Consider expert support. If you're stuck after multiple attempts, working with a certified Salesforce PDO can accelerate remediation. An outside team brings fresh eyes to security architecture, code review, and documentation — exactly the areas where repeated failures tend to cluster.

How MagicFuse Helps ISVs Pass the AppExchange Security Review

We've been building and shipping AppExchange apps since 2014. With 11+ ISV projects, 270+ Salesforce certifications, and 80+ certified specialists, we've developed a clear picture of what the Salesforce security review team looks for — and where most apps trip up.

When Elements.cloud needed a secure, scalable managed package for AppExchange, our team built the architecture from the ground up. The package passed all security reviews without issue. We also designed a Data Privacy Manager app for the same client, addressing GDPR compliance alongside the core product.

The engagement started in 2014 and continues today, with a team that's peaked at 70 and currently includes around 30 developers.

For Atamis, a Salesforce-native procurement solution, we took over a codebase that needed structural rework. We reviewed the architecture, optimized it for security compliance, prepared the security review documentation, and established a release workflow that kept things on track. The app went live on AppExchange with strong customer reviews.

We've seen similar patterns across other ISV clients. The issues that block a security review — CRUD/FLS violations, insecure external endpoints, missing documentation — tend to be the same ones, project after project.

What we help with: code reviews against Salesforce's security requirements, static code analysis, penetration testing, false-positive documentation, architecture redesign, and submission preparation. Our team works across healthcare, FinTech, non-profit, and real estate — industries where regulatory compliance (HIPAA, GDPR, PCI-DSS) adds another layer of security expectations.