AppExchange security review: what gets apps rejected
Salesforce's security review rejects most apps the first time, and almost always for the same handful of reasons. For an ISV, that first rejection is rarely a surprise attack; it is a predictable list of findings that the app was never built to avoid. The apps that pass in one round are not lucky. They were engineered against the review criteria from the first sprint. Here is what actually gets apps sent back, so you can build for the review instead of scrambling before it.
Why the review is strict, and why that is the point
Your app installs into other companies' Salesforce orgs and runs with access to their data. Salesforce's review exists to make sure a third-party package cannot leak, corrupt, or expose that data. The bar is high on purpose, and it is applied consistently, which is good news: a consistent bar is one you can build against.
The findings cluster into a short list. Master these and you have removed most of the reasons apps fail.
The findings that actually get apps rejected
Missing CRUD and field-level security enforcement. This is the number-one rejection. Apex runs in system context by default, ignoring the object and field permissions a user is normally bound by. Any query or DML that does not explicitly check access, through WITH SECURITY_ENFORCED, stripInaccessible, or manual isAccessible checks, is a finding. Code that looks correct can silently bypass the permission model, which is exactly why reviewers hunt for it.
Injection. SOQL and SOSL injection from unescaped dynamic queries, and any place user input reaches a query string without binding or escaping. The scanner catches many of these, but not all, and the human reviewer looks harder.
Sharing violations. Classes that do not declare with sharing where they should, exposing records across an org's sharing model. Getting the sharing declarations right for every entry point is tedious and routinely missed.
Insecurely stored secrets. API keys, credentials, or tokens hard-coded in Apex, in code, or in unprotected custom settings instead of protected custom metadata or named credentials. Secrets in the package are an immediate finding.
Insecure external calls. Callouts to non-HTTPS endpoints, unvalidated remote site settings, and content security policy issues in Lightning components. Anything that reaches off-platform is scrutinised for how it does so.
Sensitive data handling. Logging that captures sensitive fields, or exposing data through debug output or error messages. What your app writes to logs is part of the review.
The scanner is a first pass, not a verdict
Two mistakes bracket the review process. The first is treating a clean automated scan as a pass; the scanner has known gaps, and the human reviewer goes further. The second is treating every scanner flag as a real defect; it produces false positives that you have to triage and, crucially, document. Part of being ready is walking in knowing which flags are genuine, which are explained false positives, and which categories the scanner never checks at all.
| Approach | What happens at review |
|---|---|
| Built against the checklist from sprint one | Passes in one or two rounds; findings are minor |
| Security treated as a pre-submission step | Findings list reads like a second project; multiple rounds |
| Clean scan assumed to mean ready | Human review surfaces what the tool missed |
Build for the review, not before it
The pattern that works is not a security push before submission. It is secure-by-default coding from the first sprint: permission checks on every read and write, bound queries everywhere, correct sharing declarations, secrets in named credentials, HTTPS-only callouts, and clean logging. Do that continuously and the review becomes a confirmation rather than a gauntlet. That discipline is most of what AppExchange app development actually is, and it is why we build against the checklist from day one rather than treating review as a final hurdle.
If you have already failed, the report is your scope. It names the classes and the categories, which makes remediation estimable, and remediating someone else's findings is routine work. A rejection is a fixable state.
For ISVs weighing the whole economics of building on the platform, the review timeline is one cost among several; the Agentforce pricing math is another example of the Salesforce-ecosystem cost that hurts most when nobody modelled for it. Build against the known criteria, and the security review stops being the thing that delays your launch. Deeper Salesforce platform work sits on our Salesforce development page.
