AppExchange Security Review: How to Pass on the First Attempt

AppExchange Security Review: How to Pass on the First Attempt

CRUD/FLS enforcement failure is the #1 reason apps don’t pass the AppExchange Security Review. It’s been the #1 reason for years. And yet it catches ISVs on nearly every submission because Apex runs in system mode by default — silently bypassing the very permissions Salesforce’s security team checks for.

The AppExchange marketplace hosts over 7,000 solutions with 6 million+ customer installs. Every one of those apps passed a security review that tests for SOQL injection, cross-site scripting, CSRF, insecure authentication, improper data storage, and a dozen other vulnerability categories. A significant percentage don’t pass on their first attempt — and each failed submission costs $999 in resubmission fees plus weeks of delay.

This guide is the playbook we use at Xillentech for every AppExchange submission — DealerVogue, ConnectVogue, and every client ISV engagement. We’ll cover the top 10 vulnerabilities the security team looks for, the exact tools to run before submission, the 2GP managed package architecture that’s designed to pass, and a pre-submission checklist you can execute in your next sprint.

What the Security Review Actually Tests

The Salesforce Product Security team conducts a combination of automated scanning and manual penetration testing. They operate on a zero-trust principle: assume no user or system deserves automatic access. The review covers every component in your managed package, every external endpoint your app communicates with, and every extension package.

What they’re looking for: OWASP Top 10 vulnerabilities (injection, broken authentication, XSS, insecure direct object references, security misconfiguration, sensitive data exposure, missing function-level access control, CSRF, using components with known vulnerabilities, unvalidated redirects), Salesforce-specific security (CRUD/FLS enforcement, sharing model compliance, Lightning Locker/LWS restrictions, CSP compliance), and as of 2025, AI-specific security (data privacy in AI/ML logic, inference risks, adversarial input handling).

What it costs: $999 per submission for paid apps (free apps have no fee). If rejected, resubmission costs another $999. Annual listing fee of $150. The real cost of failure isn’t the fee — it’s the 4–8 week delay per review cycle. Two failed submissions can push your launch by 3–4 months.

The Top 10 Vulnerabilities That Cause Failures

1. CRUD/FLS Violations (The #1 Failure Reason)

Apex runs in system mode by default, bypassing object-level and field-level security. If your code performs CRUD operations without checking whether the running user has permission, you will fail. The modern fix: use User Mode in all SOQL queries (WITH USER_MODE) and DML operations (Database.insert(records, AccessLevel.USER_MODE)). Document any intentional CRUD/FLS bypasses (aggregates, system metadata, logs) as part of your submission.

2. SOQL Injection

Occurs when unvalidated user input is inserted into dynamic SOQL queries. Prevention: use static queries with bind variables instead of string concatenation. If dynamic queries are unavoidable, use String.escapeSingleQuotes(), typecasting, or input whitelisting. Code Analyzer, PMD, and Checkmarx all flag this.

3. Cross-Site Scripting (XSS)

Both stored XSS (malicious input saved to database and rendered to other users) and reflected XSS (malicious input in URLs executed on click). In Lightning, the Content Security Policy and Lightning Locker/LWS provide built-in protection, but improper use of lwc:dom=“manual” or unsanitized dynamic rendering bypasses these. Every user-supplied string rendered in the UI must be escaped.

4. Cross-Site Request Forgery (CSRF)

Salesforce provides built-in CSRF protections via anti-CSRF tokens on standard forms. But custom REST endpoints and Visualforce pages with custom forms can bypass these protections if not properly implemented. Always use the built-in CSRF token mechanism for any form submission.

5. Insecure External Endpoints

Every HTTP callout your app makes is scrutinized. All external communications must use HTTPS (TLS 1.2+). Certificates must be valid and not self-signed. API keys and secrets must never be hardcoded — use Named Credentials or Protected Custom Metadata. External endpoints must implement proper authentication (OAuth 2.0 preferred).

6. Improper Data Storage

Sensitive data (passwords, tokens, PII) stored in plaintext in custom settings, custom objects, or static resources. Use Platform Encryption, Protected Custom Metadata Types, or Named Credentials. Never store secrets in Custom Labels, Custom Settings (visible to admins), or unencrypted custom fields.

7. Insufficient Sharing Model Enforcement

Apex classes that don’t declare ‘with sharing’ default to system mode, ignoring org-wide defaults, role hierarchies, and sharing rules. Every Apex class should explicitly declare ‘with sharing’ or ‘inherited sharing.’ Use ‘without sharing’ only when intentionally escalating privileges, and document why.

8. Lightning Component Security (CSP/LWS)

Lightning Web Components share the same origin as Salesforce-authored code, so restrictions are strict. No inline JavaScript in HTML. No inline CSS that could affect other components. No external JavaScript except via static resources. No use of fixed, absolute, or float positioning in CSS (components must be modular). Don’t use .THIS in LWC (only required for Aura). CSS violations are a surprisingly common failure reason.

9. Outdated Third-Party Libraries

Any JavaScript or Apex library included in your package is evaluated. Libraries with known CVEs will fail the review. Keep all dependencies current. Use RetireJS (included in Code Analyzer) to scan for vulnerable JavaScript libraries. Remove any unused libraries — they increase attack surface with zero benefit.

10. Incomplete or Misleading Documentation

Poor documentation slows reviewers and triggers additional scrutiny. Provide test environment credentials, step-by-step setup guides, architecture diagrams, and explicit documentation of any CRUD/FLS bypasses or elevated privilege patterns. Explain every false positive in your Checkmarx/Code Analyzer reports with mitigation details and links to Salesforce documentation.

The Security Testing Toolkit: Run These Before You Submit

Salesforce Code Analyzer v5 (Free, CLI + VS Code + GitHub Actions): 500+ built-in rules across Apex, Visualforce, LWC, and Flows. The Graph Engine DFA scanner is the only tool that fully supports User Mode detection in both SOQL and DML. Run sf scanner run and sf scanner run dfa on every class. This is your primary pre-submission gate.

Checkmarx (Via Partner Security Portal): Salesforce’s official SAST tool for AppExchange submissions. Integrate into your CI/CD pipeline. Generates reports the security team expects to see in your submission. Note: Checkmarx throws false positives on User Mode DML — document these in your false positive report.

OWASP ZAP (Free, open source): Dynamic Application Security Testing (DAST) for any external web applications, APIs, or endpoints your package communicates with. Replaced the retired Chimera DAST Scanner (retired June 2025). Required for any app with external web components.

Burp Suite (Commercial): Enterprise-grade DAST alternative to ZAP. More comprehensive for complex web applications and API testing. Simulates real-world attacks against your external services.

RetireJS (Included in Code Analyzer): Scans JavaScript static resources for known vulnerable library versions. Any library with a published CVE will fail security review. Run this before every submission.

The 2GP Architecture That’s Designed to Pass

Second-generation managed packages (2GP) are the current standard for AppExchange submissions. Built using Salesforce CLI and scratch orgs, 2GP packages support modular development, unlocked package dependencies, and modern CI/CD pipelines. The architecture decisions you make at the package level determine whether security review is a formality or a nightmare.

CLEAN Architecture for Security Review

Controllers (thin, UI-facing): Contain no business logic. Accept input, delegate to Services, return output. All input validation happens here — every parameter sanitized before passing to the Service layer.

Services (business logic): All CRUD operations use User Mode by default. Sharing model enforced via ‘with sharing’ declaration. No dynamic SOQL unless absolutely necessary (and if so, bind variables only).

Domains (object-specific logic): Trigger handlers with ‘inherited sharing.’ One trigger per object, delegating to domain classes. Bulkified by design — no single-record patterns that hit governor limits.

Selectors (data access): All SOQL centralized in Selector classes with WITH USER_MODE. No inline queries anywhere in the codebase. This single pattern addresses the #1 failure reason (CRUD/FLS) at the architectural level.

Why CLEAN matters for security review: When every query goes through a Selector with User Mode, and every DML goes through a Service with User Mode, CRUD/FLS enforcement is structural — not something developers remember to add per-query. The security team sees consistent, auditable patterns instead of scattered checks. This is how DealerVogue and ConnectVogue pass review: the architecture prevents violations by design, not by discipline.

The Pre-Submission Checklist: 15 Items

1. All SOQL queries use WITH USER_MODE or explicit CRUD/FLS checks

2. All DML operations use AccessLevel.USER_MODE or explicit CRUD/FLS checks

3. All Apex classes declare ‘with sharing’ or ‘inherited sharing’ (document any ‘without sharing’ with justification)

4. No dynamic SOQL with string concatenation (use bind variables exclusively)

5. All user-rendered output is escaped (no raw HTML injection possible)

6. All external HTTP callouts use HTTPS with TLS 1.2+

7. No hardcoded credentials, API keys, or secrets (use Named Credentials or Protected Custom Metadata)

8. No inline JavaScript in Lightning components (all JS in component bundles)

9. No inline CSS that uses fixed, absolute, or float positioning

10. All third-party JavaScript libraries scanned with RetireJS (zero known CVEs)

11. Code Analyzer v5 run with zero critical/high findings (document false positives)

12. Checkmarx scan completed via Partner Security Portal (report included in submission)

13. OWASP ZAP or Burp Suite scan on all external endpoints (report included)

14. Test environment configured with admin + standard user credentials provided

15. Documentation package complete: setup guide, architecture diagram, permission model, false positive explanations, CRUD/FLS bypass justifications

What to Do If You Fail (And How to Recover Fast)

Don’t panic. The security team provides a detailed feedback report listing vulnerability classes found. Note: the report is not exhaustive — it lists classes of vulnerabilities, not every instance. If they found CRUD/FLS violations in 3 classes, assume they exist in 30.

Treat each finding as a class of issues, not individual bugs. A SOQL injection finding means audit every dynamic query in the codebase. An XSS finding means audit every user-rendered output. Fix the pattern, not just the instance.

Attend Security Review Office Hours. Salesforce offers regular office hours where you can discuss your findings with the Product Security team directly. Use them — personalized guidance is faster than guessing.

Budget 2–4 weeks for remediation per failed attempt. Resubmission enters the same review queue. If you fail twice on the same vulnerability class, the third review will face increased scrutiny. Fix it properly the first time.

How Xillentech Approaches AppExchange Security

Security is an architecture decision, not a review-time fix. Our CLEAN architecture enforces CRUD/FLS, sharing model, and input validation at the structural level. DealerVogue’s entire data access layer runs in User Mode via centralized Selectors. ConnectVogue’s BYOK architecture implements tenant isolation with zero hardcoded IDs and Named Credentials for all external connections.

CI/CD with security gates: Code Analyzer runs on every pull request. Checkmarx runs before every package version creation. No package version ships with critical or high findings. False positives are documented in a maintained registry.

PDO services for ISV clients: As a Salesforce ISV + Consulting Partner, we offer Product Development Outsourcing (PDO) for ISVs who need help building packages that pass security review. The Vogue Protocol’s CLEAN architecture and TDD methodology are designed from the ground up for AppExchange compliance.