Connected Apps (CAs) and External Client Apps (ECAs) AppExchange Security Review Submission Guidance

This article answers: what does Salesforce check during an AppExchange security review of a package's Connected Apps and ECAs, and what should be included in the submission?

Packaging Requirements

New integrations must use ECAs instead of Connected Apps. CAs and ECAs should be packaged for distribution on AppExchange. There are use cases where packaging is mandatory, shown in the table below. In other cases an ECA may need to be created on the subscriber org after installation — if that applies, document the use case in your submission.

Don't delete existing Connected Apps or ECAs from the org, or remove them from the package, before evaluating the impact of that action. If you have packaging questions, reach out to customer support.

Security Practices

Follow these practices for your app's OAuth configuration and coding:

• Onboard your CA/ECA to the security controls documented in the Connected Apps and ECA secure coding guide.
• Apps must not rely on these OAuth flows: device flow; implicit grant flow; username/password flow (retiring in Winter '27).
• Apply the principle of least privilege when using scopes. If your app requires web or full scope, submit a comprehensive justification — for example, a real authentication protocol that supplements that scope. If you use web scope, your app must not extract the session ID from the frontdoor URL.
• Avoid mixed-use callback URLs in a single app: use separate apps for public and confidential clients, and don't combine a localhost callback URL with any other callback URL.
• Use an OAuth token instead of a session ID when invoking the metadata API in Apex. See Security Considerations for Session IDs, and sample Connected App and ECA implementations.

Subscriber-Created CAs/ECAs and Packaged Secrets

• Use protected custom settings to store subscriber-owned secrets.
• Use protected custom metadata to store packaged secrets.
• This requires the subscriber to rotate secrets regularly and document how the secrets can be updated.

Securing Secrets with Third-Party Applications

Robust security measures must protect the secrets used in CA/ECA use cases — including secure packaging, safeguarding the client key, client secret, encryption keys, and certificates within web applications, and securely storing auth and refresh tokens.

• Public clients must not rely on a client secret for OAuth flows.
• Rotate the client ID and client secret regularly.

Find more information in the OWASP Secrets Management Cheat Sheet.

Submission Documentation

• Disclose in detail how Connected Apps and ECAs are used within the solution.
• Document and explain how secrets are secured.
• For packaged ECAs, share the client key in the submission documents only — don't share the client secret.
• Submit credentials for integrations, including web apps and REST APIs, to avoid delays in the security review.
• If the CA/ECA is packaged independently or as an extension package, include details of the base package.
• ISVs must submit detailed documentation on how secrets are secured on their backend infrastructure.

Securing Packaging Orgs (1GP), Namespace Definition Orgs (2GP), and DevHubs

Robust security measures are essential for the integrity of these critical organizational environments.

• ISVs must keep contact information current and ensure the designated contact person is responsive.
• No user in these orgs should have the Use Any API Client permission.
• Restrict access: enforce multi-factor authentication (MFA) for all users, and use IP allowlisting.
• These orgs must not have untrusted Connected Apps or ECAs installed, and must not host sites that allow guest user access.
• Don't install untrusted packages on these orgs.
• Rotate secrets regularly: rotate user passwords (including API users) at least once a year, and rotate the client key, client secret, and certificate regularly.

Reporting Suspicious Activity

Report any suspicious activity or security incident affecting your applications or their customer secrets immediately by emailing security@salesforce.com for investigation.