Getting an AppExchange listing live is rarely blocked by big architectural ideas. It’s usually stopped by small, repeatable security gaps that show up during the Salesforce Security Review. For ISVs, that can be frustrating: you’ve built a solid product, you’ve packaged it, you’ve prepared the listing, then the AppExchange Security Review comes back with findings that delay your launch and pull engineering time away from roadmap work.
A clean pass is much more achievable when security review prep is treated as part of build, not a final hurdle. That means a pre-review checklist, a short internal “security audit” sprint and a clear way to prove to reviewers that your app protects customer data.
Kandisa Tech has been a proud partner of getting many apps live on AppExchange app.
You can see the apps here:
So, we bring you this guide to break down the most common rejection reasons seen during AppExchange app reviews, what triggers them and what “good” looks like in practice. If you’re an ISV building for customers in the UK, Dubai or Australia/NZ, the same fundamentals apply, with a bonus emphasis on data residency expectations, customer due diligence and tighter security questionnaires during procurement.
What the AppExchange Security Review is really testing
The AppExchange Security Review is designed to validate that your solution is secure by design and safe to install in customer orgs. Reviewers look at how your package behaves inside Salesforce, how it handles permissions, how it processes input, how it stores and transmits data and how it interacts with external services.
Your submission is also assessed as an end-to-end solution. That includes the managed package, any connected services, authentication flows and the materials you provide (test credentials, configuration steps, documentation and scan/pen test artefacts where required).
Common rejection reasons (and what to fix before you submit)
1) CRUD and FLS are not enforced everywhere
This is one of the fastest ways to fail a security review.
What triggers it
- Apex runs queries or DML on objects/fields the running user should not access
- LWC/Aura components expose data without checking field-level security
- “With sharing” is missing where it should exist or sharing is being bypassed
How to fix
- Enforce CRUD/FLS checks consistently in Apex and UI layers
- Use patterns that verify object access and field access before reads/writes
- Validate access again in service classes, not only in controllers
Why it matters
A package that ignores FLS can leak sensitive fields (salary, personal IDs, billing info) even if the UI hides them.
2) Insecure direct object reference and over-broad queries
This shows up when records are fetched by ID without validating access or when a query returns more than the user should see.
What triggers it
- Querying by Id with no sharing enforcement or filter controls
- Returning full sObjects when you only need a few fields
- Exposing record IDs in client-side code without server-side controls
How to fix
- Use least-data patterns: return only required fields
- Apply sharing, filter by allowed scope and verify ownership/role rules as needed
- Avoid “query everything then filter in code”
3) Injection risks (SOQL, SOSL, dynamic queries)
Dynamic queries are not banned, but unsafe dynamic queries are.
What triggers it
- User input concatenated into SOQL/SOSL
- Dynamic ORDER BY built from uncontrolled input
- Filters passed from UI to Apex without validation
How to fix
- Use bind variables
- Whitelist allowed sort fields and directions
- Validate all inputs, even if you think they are coming from “trusted” UI
4) Cross-site scripting and unsafe rendering in UI
If your components render untrusted content into the DOM, reviewers will flag it.
What triggers it
- Rendering HTML from user input
- Unsafe use of rich text without sanitisation
- Passing user input into navigation or URL builders without encoding
How to fix
- Treat all user-provided strings as hostile until sanitised
- Encode output properly
- Avoid raw HTML insertion patterns and unsafe client-side templating
5) Missing CSRF protections in Visualforce or custom endpoints
If your solution includes Visualforce, custom controllers or endpoints that mutate data, reviewers will examine request integrity.
What triggers it
- State-changing actions without CSRF protections
- Weak validation around session/context
- Endpoint operations reachable without adequate checks
How to fix
- Use platform-provided protections where available
- Require valid sessions and verify intent for state changes
- Keep mutation actions server-side with proper guards
6) Hardcoded secrets, tokens and credentials
This is a surprisingly common rejection reason, often caught by static scans.
What triggers it
- API keys in Apex or JavaScript
- Credentials in Custom Labels used as “config”
- Tokens committed in repo history and pushed into the package build
How to fix
- Use secure storage patterns (Named Credentials for outbound auth)
- Rotate any exposed keys immediately
- Implement a secrets management approach for external services
7) Weak authentication and authorisation for external integrations
Many AppExchange apps connect to external services. That surface area is heavily tested.
What triggers it
- Basic auth where OAuth is expected
- Home-grown token storage with no rotation strategy
- No validation around scopes, user mapping or expiry
How to fix
- Prefer OAuth flows appropriate to your integration
- Use Named Credentials and External Credentials where possible
- Implement least-privilege scopes and clear revocation
8) Insecure transport or missing TLS controls
Outbound calls, callbacks, webhooks and embedded resources can fail review if transport security is weak.
What triggers it
- Non-TLS endpoints
- Mixed content in UI (loading assets over HTTP)
- Weak endpoint validation and redirect handling
How to fix
- Enforce TLS-only communication
- Validate callback URLs and redirect URIs
- Maintain a clear inventory of endpoints and domains your app uses
9) Sensitive data is stored or logged in unsafe ways
Security review teams look for accidental data exposure in logs, debug output or persistent storage.
What triggers it
- Storing PII in plaintext custom objects without a clear need
- Writing tokens, session identifiers or personal data to logs
- Returning sensitive fields in responses “just in case”
How to fix
- Store the minimum data required for the feature
- Mask or avoid logging sensitive values
- Use encryption strategies when the use case demands storage
10) Guest user access, Experience Cloud misconfigurations
If your app touches sites/portals or guest users, the bar gets higher.
What triggers it
- Guest user can read or write data unintentionally
- Sharing rules are too permissive
- Public endpoints accept changes with weak check
How to fix
- Lock down guest access
- Validate sharing and object permissions across personas
- Re-check all unauthenticated entry points
11) Over-privileged permission sets or “admin required” design
A frequent review outcome is: “Your app requires too much access.”
What triggers it
- Asking for Modify All Data when not essential
- Profiles/permission sets granting broad object rights
- Setup features exposed without adequate controls
How to fix
- Design for least privilege
- Split permissions by feature set
- Document why each permission is needed, with exact user impact
12) Outdated or vulnerable third-party libraries
If you bundle libraries in LWC, static resources or connected services, they’ll be examined.
What triggers it
- Known vulnerable versions (client-side or server-side)
- No SBOM-style inventory of dependencies
- Libraries that are abandoned or unmaintained
How to fix
- Keep dependencies current
- Maintain a dependency list and upgrade plan
- Scan for known vulnerabilities as part of CI/CD
13) Unclear reviewer instructions, missing setup steps, weak test environment
Not every rejection is a code flaw. A lot of delays happen because the review team can’t reproduce flows.
What triggers it
- Test org credentials not working
- Steps are incomplete or assume product knowledge
- External services not accessible in the test environment
- Missing endpoints, sample data or feature flags
How to fix
- Provide a clean, repeatable setup guide
- Include test users for each persona with clear permissions
- Provide predictable sample records and instructions for key flows
A practical pre-review checklist ISVs can run in one sprint
Step 1: Run static analysis early, not the night before
Salesforce provides guidance and tooling options for scanning your code. Static analysis won’t catch everything, yet it finds many “easy fail” issues fast, especially around CRUD/FLS, injection patterns and risky APIs.
Step 2: Do a targeted threat-model pass
Ask a few blunt questions:
- What’s the worst-case data exposure in each feature?
- What entry points accept input (UI, API, callbacks)?
- Which parts touch external services?
- Where do you store identifiers, tokens and logs?
You’ll catch weak spots before a reviewer does.
Step 3: Validate permissions with real-world personas
Create test users with realistic profiles and permission sets:
- Minimum-access user
- Standard user
- Admin/config user (only where required)
Run end-to-end flows with the minimum-access user. If anything breaks, don’t “fix” it by expanding access. Fix it by tightening code and reducing assumptions.
Step 4: Confirm every integration endpoint is documented
List:
- Domains used
- Auth method
- What data is sent and received
- Error handling
- Retry behaviour
- How a customer can revoke access
That one page saves days of back-and-forth.
Step 5: Make a review-ready submission pack
A submission that moves quickly usually includes:
- Working test credentials
- Clean setup steps (copy/paste friendly)
- Known limitations (clearly stated)
- Security scanning outputs and what was done about findings
- Clear explanation of any sensitive permissions
Salesforce outlines required materials and preparation expectations in their ISV packaging and security review guidance.
Conclusion
If you’re preparing an AppExchange listing and want to reduce rework during the AppExchange Security Review, a short Salesforce Security Review prep sprint can be run before submission. That typically covers managed package security, CRUD/FLS enforcement checks, input validation review (SOQL injection, XSS, CSRF), endpoint and OAuth hardening, dependency scanning and a reviewer-ready submission pack.
Want a pre-review readiness report in 7–10 business days?
Send:
- Package type (managed package / 2GP) and primary clouds used
- External integrations (OAuth, webhooks, APIs)
- Any use of Visualforce, sites/portals or guest access
- Dependency list (libraries, static resources, external services)
- Target listing timeline (UK, Dubai, AU/NZ launch window)
You’ll get a prioritised fix list, clear remediation guidance and a clean path to submit with confidence.