Passing the Salesforce Security Review: What It Takes

Every app on AppExchange has to pass Salesforce's security review. No exceptions. For ISVs, it's often the hardest part of getting to market. For customers, it's why AppExchange apps are generally safer than custom integrations. Here's what actually happens.

The tools they run

The review isn't just manual inspection. Salesforce runs automated scans before and during the process.

SAST (Static Application Security Testing). Your code is scanned by Checkmarx — the mandatory SAST tool for AppExchange submissions. It analyzes Apex, Visualforce, and Lightning Web Components for vulnerabilities. You get access through the Partner Security Portal (typically 3 free scans per review). Salesforce also provides Code Analyzer, a CLI tool you can run yourself during development. Both catch issues like injection, XSS, and missing CRUD/FLS before the review team even looks at your app.

Dynamic scanning and pen testing. If your app exposes API endpoints — for example, callbacks from external systems or REST APIs — Salesforce runs OWASP ZAP (Zed Attack Proxy) against them. ZAP performs active scanning and penetration testing: it probes your endpoints for common web vulnerabilities. Other options like Burp Suite or Chimera (for Heroku-hosted apps) may also be used. The point is: external surfaces get tested, not just your Salesforce code.

Third-party components. Tools like retire.js scan for vulnerable and outdated JavaScript libraries. If you're pulling in third-party code, it needs to be current. Outdated dependencies are a common failure reason.

You can run many of these tools yourself before submitting. Doing so catches the same issues the review would flag and saves revision cycles.

What they look at

The review covers code, data handling, connected apps, and documentation. The findings often map to the [OWASP Top 10](https://owasp.org/Top10) — the standard list of the most critical web application security risks. Broken access control (A01), injection (A03), cryptographic failures (A02), and insecure design (A04) show up constantly in AppExchange rejections.

Code. They scan for SOQL injection (dynamic queries without bind variables), XSS (unencoded user input), and missing CRUD/FLS checks. They check whether your Apex runs with `with sharing` and whether you're respecting the user's permissions. Hardcoded credentials are an instant fail.

Data. Sensitive data must be encrypted. External calls must use HTTPS. Credentials should live in Named Credentials, not custom settings. You need to document how you handle, store, and delete data.

Connected apps. If you use OAuth, they look at scope (least privilege), token handling, and what happens when the app is uninstalled. After the 2025 OAuth breach, Salesforce tightened this. Apps requesting `full` or `api` scope when they don't need it get flagged. Uninstalled apps are blocked by default.

Documentation. You need to explain what your app does, what data it touches, and why it needs the permissions it requests. Vague or missing docs slow the review and often cause rejection.

Why apps fail

The most common failure is missing CRUD/FLS checks. Every query and DML operation has to respect the user's permissions. Using `WITH USER_MODE` (Spring '23+) is the modern approach. If your code bypasses object or field-level security, you'll fail.

Other frequent issues: HTTP instead of HTTPS for callouts, credentials in custom settings instead of Named Credentials, overly broad OAuth scope, and Lightning components that don't sanitize user input or expose sensitive data in the browser.

Documentation is underrated. The review team can't evaluate what they don't understand. If your architecture doc is thin or missing, expect questions — and often a rejection until you clarify.

How to prepare

Run the same tools they run. Use Salesforce Code Analyzer and Checkmarx (via the Partner Security Portal) on your code before you submit. If you have external API endpoints, run OWASP ZAP against them. Fix everything these tools report. The review team will run the same scans — if you've already addressed the findings, you avoid the obvious rejections.

Build security in from the start. Retrofitting is painful. Use `with sharing` by default. Use `WITH USER_MODE` in SOQL. Use Named Credentials for every external integration. Validate input and encode output. If you establish these patterns early, you avoid most of the common failures.

Document your architecture. Write down what data you access, how external integrations work, what permissions you need and why, and how data is encrypted. Make it clear enough that someone who doesn't know your codebase can understand it.

Plan for time. Initial review takes 4–8 weeks, sometimes longer during busy periods. First submissions often need revisions. Factor in at least one revision cycle when you're planning your launch.

What passing actually means

Passing the review isn't a formality. It means your app has been checked by people who look for things automated tools miss. For customers, that's a real quality signal. For ISVs, it's a credibility stamp. The discipline required to pass — proper FLS, encrypted data, minimal permissions — is what enterprise customers should expect from any software they install.