Salesforce Security Review Checklist: What to Fix, In Order

Most AppExchange submissions fail on a short, predictable list, and access control sits at the top of it. Work this checklist in order, user-mode access enforcement first, scanner triage second, submission materials third, and you remove most of the reasons a reviewer sends a package back. Salesforce puts a typical review at 4 to 5 weeks, so a rejection costs you a release cycle, not an afternoon.

Tekunda has taken managed packages through AppExchange security review in healthcare, logistics and manufacturing. What follows is the order we work in, not a description of the process.

What gets a Salesforce security review submission rejected?

Fix these top to bottom. The items near the top are both the most common findings and the most expensive to retrofit, which is why leaving them until last is how a submission slips a cycle.

1. Access control that is not enforced in user mode. Every query and DML operation in your package has to respect the running user's object permissions, field-level security and sharing. Prefer WITH USER_MODE on SOQL and AccessLevel.USER_MODE on Database calls over hand-rolled isAccessible() chains, which are easy to leave incomplete.
2. Sharing declared on the wrong classes. An Apex class with no sharing keyword inherits sharing from its caller, so a helper invoked from an @AuraEnabled method can quietly run without it. Declare with sharing explicitly on every class, including inner and utility classes.
3. Dynamic SOQL assembled from input. Use bind variables. If a query genuinely has to be built as a string, escape every interpolated value and keep that escaping visible in the same method, because that is where a reviewer reads it.
4. Unescaped output. Anything reaching the page through escape="false", lwc:dom="manual" or innerHTML has to be sanitised before it gets there, not after.
5. Secrets and customer data in the wrong place. Hardcoded keys in Apex, tokens in custom settings, a record with personal data passed to System.debug. Named Credentials and protected custom metadata are what reviewers expect instead.
6. External endpoints nobody scanned. If your package calls a service you operate, that service is in scope and needs its own dynamic scan report.
7. A test environment the reviewer cannot use. An expired org, an identity challenge that locks them out, or objects with no data in them. The team drives your solution end to end like a customer would, and it cannot review what will not run.

Which scanner findings are false positives, and how do you document them?

The bar is not zero findings, and it is different for each scanner. Salesforce's own preparation guidance sets it out:

• Salesforce Code Analyzer: fix every security-related error, and disregard findings that are not security related.
• Partner Security Portal source scan: fix Low, Medium and High, and leave informational warnings alone.
• Dynamic scanners such as ZAP, Burp Suite, Veracode, Intruder, Acunetix and JiT DAST: fix everything except informational items and warnings, and attach a screenshot proving the right endpoint was scanned.

Since Salesforce retired the hosted Chimera scanner on 2025-06-16, you run that dynamic scan yourself. See Running Your Own Dynamic Scans After Chimera for the accepted tools and the report to submit.

Across our submissions, four categories come back as genuine false positives often enough to plan for: access-control findings raised against code that already enforces user mode, sharing findings on classes only ever entered through a context that has applied sharing, retired-library findings matched on a version string inside a bundled static resource, and reflected cross-site scripting findings on parameters that never reach the DOM.

Being right is not enough, though. The document is what passes. Salesforce asks for a document explaining why each flagged item does not pose a security risk, and tells you to be specific about how you protect against the vulnerability indicated. Give every finding its own entry: scanner and rule identifier, file and line, one sentence describing the data path, the exact control that protects it, and where that control lives in the package. One-line dismissals come back as questions, and questions cost weeks. For a deeper walkthrough of the justification format and the mistakes that get it rejected, see How to Document False Positives for the Salesforce Security Review.

What goes into the submission besides the package?

• Usage documentation written so that someone who has never seen the app can complete a full workflow.
• Data flow documentation between the Salesforce org and any composite site, mobile app or browser extension.
• Every scan report, plus the false positive document.
• A Developer Edition org with the package installed and realistic seeded data.
• Credentials for each external system the app touches, covering API, OAuth and SAML access.
• Install links and credentials for any mobile or desktop client.

How long does the security review take, and what does it cost?

Salesforce states that a solution typically takes 4 to 5 weeks to get through the review, and that for every paid solution sold on the marketplace there is a $999 fee for the initial submission and for any subsequent attempts. Both facts argue for the same thing: front-load the access control work, because the cheapest submission is the one you only have to make once.

If you are packaging a product and would rather the review was handled by people who have cleared it before, Tekunda builds and packages AppExchange products as a Salesforce PDO.

FAQ

Do free apps need a security review?

Yes. Every solution distributed on the marketplace has to pass the review before it is listed. The submission fee that Salesforce documents applies to paid solutions.

Is Salesforce Code Analyzer enough on its own?

No. Code Analyzer v5 covers the Apex, Visualforce, JavaScript and TypeScript inside your package. Any external endpoint your app calls still needs a dynamic scan report of its own.

What is the single most common reason for rejection?

Access control. Queries and DML running in system mode, and classes that inherit sharing instead of declaring it, produce more findings than anything else we see.

Does an Agentforce or agent-based app change the checklist?

The same security review applies to agentic solutions. The difference shows up in the data flow documentation, because every external service your agent can call has to be described and scanned.