Third-Party App Security: Evaluating AppExchange Packages

1. The Salesforce AppExchange Security Ecosystem and the Security Review

The Salesforce AppExchange is a powerful marketplace, enabling organisations to rapidly extend platform capabilities through third-party packages. However, installing external code directly into an enterprise environment introduces significant compliance, governance, and security risks. To mitigate these threats, Salesforce enforces a comprehensive AppExchange Security Review. Understanding the mechanics, depth, and inherent limitations of this review is the first line of defence for CTOs and solution architects evaluating external solutions.

The AppExchange Security Review is a mandatory, rigorous assessment that every commercial application must undergo before being listed on the public AppExchange. This process combines automated source code analysis with manual penetration testing conducted by Salesforce's internal security engineering team. The review spans multiple layers: static application security testing (SAST) using advanced scanning tools to identify vulnerabilities such as SOQL injection, cross-site scripting (XSS), and insecure sharing configurations in Apex; and dynamic application security testing (DAST) to evaluate the application's behaviour in a live environment. If the application connects to an external web service, Salesforce's engineers perform dynamic penetration testing on the vendor's external infrastructure, validating that the external server is secure against common web vulnerabilities, enforces strong transport-layer security (TLS 1.2+), and adheres to secure authentication standards.

While the Security Review represents an industry-leading standard for SaaS security, enterprise security officers must recognize its limitations. The AppExchange Security Review is a point-in-time assessment. Once a package is approved, subsequent minor updates or changes to the vendor's external servers may not be instantly re-evaluated by Salesforce with the same level of depth. Furthermore, the review certifies that the package does not contain malicious code or blatant vulnerabilities, but it does not guarantee that the package aligns with your organisation's specific data privacy policies or regulatory compliance mandates. For instance, a certified app may still legitimately transmit customer data to an external server if that is its stated function; it is the customer's responsibility, not Salesforce's, to ensure that this data transfer is legally compliant and fits within the corporate risk profile. Therefore, the AppExchange Security Review must be viewed as a baseline entry criteria, not a replacement for a rigorous internal security evaluation.

2. Managed vs Unmanaged Packages: Security and IP Boundaries

When evaluating third-party packages, architects must distinguish between managed and unmanaged packages. These two formats offer vastly different technical structures, upgrade mechanisms, and security boundaries. Understanding how they operate is crucial for maintaining an audit-ready metadata footprint and protecting intellectual property (IP).

Managed Packages are the primary vehicle for commercial AppExchange products. They are designed as sealed, version-controlled containers. The most notable security feature of a managed package is code obfuscation: the source Apex code within a managed package is completely hidden from the subscriber organisation, with the sole exception of classes and methods explicitly marked as global. This intellectual property protection prevents subscribers from modifying or copying the underlying proprietary logic. From a security perspective, managed packages enforce a strict namespace boundary. The package operates within its own dedicated namespace (e.g., acme__), which prevents naming collisions with the subscriber's custom configurations and isolates the package's internal classes. In addition, managed packages support seamless upgrade paths, allowing vendors to push security patches and bug fixes directly to subscriber orgs without manual redeployment. However, code obfuscation makes internal static code analysis impossible for the customer; you must rely on the vendor's security certifications and external audit reports to verify the safety of their code.

Unmanaged Packages, on the other hand, are essentially open-source templates. When installed, all components—including Apex classes, triggers, pages, and custom fields—are deployed directly into the subscriber's default namespace as if they were written by the subscriber's own developers. This layout provides complete visibility; security teams can run static analysis tools directly on the unmanaged code, review every line of Apex, and customise the code to fit their exact security requirements. However, this absolute flexibility comes with severe governance drawbacks. Unmanaged packages have no upgrade path. If the vendor releases a security patch, the subscriber must manually review, refactor, and redeploy the code, which frequently leads to configuration drift and unpatched vulnerabilities. Furthermore, because unmanaged code runs directly in the subscriber's namespace, it can easily interact with other customisations, increasing the risk of accidental data leakage or privilege escalation if the code is not carefully audited and maintained by the internal development team.

3. A Structured Framework for Auditing Package Permissions and Apex Access

Upon installing any package, especially a managed package, a key architect task is to execute a granular permission audit. Packages often ship with broad permission sets, custom profiles, or Apex classes that execute in system mode (without sharing). A structured framework is required to restrict package permissions to the absolute minimum necessary for its business function.

The audit begins by reviewing the Permission Sets and custom fields deployed by the package. Architects must map every permission set provided by the vendor to identify the exact CRUD (Create, Read, Update, Delete) and FLS (Field-Level Security) privileges granted. Many vendors request broad access to core standard objects (like Accounts, Contacts, or Opportunities) to simplify installation. If the application only requires read-only access to Accounts, but the packaged permission set grants full Edit or Delete access, the architect must decline the default permission set and instead configure a custom permission set that restricts access. Furthermore, architects must inspect the packaged Apex triggers and classes. Triggers in Salesforce run in system context by default. If a packaged trigger executes without sharing, it can read and write data across the entire database, completely bypassing the subscriber's sharing rules and role hierarchy. While some system-level execution is necessary for utility functions, any business logic that handles sensitive customer data should enforce user sharing models. Developers should audit packaged Apex classes (where visible) or require documentation from the vendor detailing their sharing modes.

// Example of auditing query permission metadata programmatically in Apex
public static void auditPackagePermissions() {
    List pkgPermSets = [
        SELECT Id, Name, Description 
        FROM PermissionSet 
        WHERE NamespacePrefix = 'acme'
    ];
    for (PermissionSet ps : pkgPermSets) {
        System.debug('Auditing Perm Set: ' + ps.Name + ' | Description: ' + ps.Description);
    }
}
        

In addition to object-level access, architects must audit custom Apex page overrides, Aura components, and Lightning Web Components (LWCs) packaged by the vendor. These components must enforce strict FLS and CRUD checks during rendering and execution. If a packaged LWC queries data using an Apex controller that does not explicitly enforce FLS, a standard user could potentially view sensitive fields that their profile should restrict. To prevent this, the internal audit must demand that all packaged controllers utilise standard enforcement mechanisms, such as the WITH USER_MODE SOQL clause or the Security.stripInaccessible method, ensuring that data exposure is dynamically limited to the logged-in user's rights.

// Demonstrating the enforcement of user mode in dynamic Apex to prevent data exposure
public with sharing class PackagedDataController {
    @AuraEnabled(cacheable=true)
    public static List getContactsSecure(String searchKey) {
        // Enforcing USER_MODE guarantees that standard FLS, CRUD, and sharing are automatically respected
        return [
            SELECT Id, FirstName, LastName, Email 
            FROM Contact 
            WHERE LastName LIKE :searchKey 
            WITH USER_MODE
        ];
    }
}
        

4. Verifying Data Flow Boundaries and External Integrations

A primary source of security risk in third-party packages is the transfer of data outside the Salesforce boundary to external servers managed by the vendor or third-party service providers. To verify data flow boundaries, architects must systematically audit the integration configurations established by the package: Remote Site Settings, Named Credentials, and Content Security Policy (CSP) Trusted Sites.

Remote Site Settings are the legacy mechanism for permitting outbound HTTP callouts from Apex. By default, Salesforce prevents any Apex class from calling an external URL unless that URL is explicitly registered in the Remote Site Settings list. When installing an AppExchange package, the installation wizard often prompts the administrator to approve one or more remote sites. Architects must scrutinise these endpoints. A common risk is "scope creep," where a package requests access to a broad domain (e.g., *.amazonaws.com) rather than a specific, dedicated bucket endpoint. This broad access allows any malicious code within the org to transmit data to any AWS account, creating a significant data exfiltration risk. The best practice is to restrict remote site endpoints to the absolute most specific URL possible, and actively monitor changes to this metadata.

-- SOQL query to audit active Remote Site Settings and their target endpoints
SELECT DeveloperName, EndpointUrl, IsActive, Description FROM RemoteSiteSetting
        

Named Credentials offer a modern, highly secure alternative to Remote Site Settings by combining the endpoint URL and the authentication parameters (such as OAuth tokens or certificates) into a single, managed configuration. Because Named Credentials abstract the authentication logic away from the Apex code, they prevent vendors from hardcoding passwords or secret keys directly within their compiled package classes. During the security audit, architects must verify that the package utilizes Named Credentials for all external integrations. Furthermore, CSP Trusted Sites must be reviewed. CSP sites control where the user's web browser is allowed to send front-end requests (such as AJAX calls) from Lightning components. If a package registers a broad CSP Trusted Site, it could potentially allow front-end components to exfiltrate user session data or keystrokes to an unapproved external server. Every CSP Trusted Site must be validated against the vendor's documented data architecture, ensuring no unauthorised third-party tracking domains are permitted.

5. Continuous Monitoring of OAuth Authorizations and Connected Apps

The final pillar of a third-party app security framework is the continuous monitoring and governance of OAuth authorizations and Connected Apps. Many AppExchange packages install a Connected App within the subscriber organisation. This Connected App acts as a secure gateway, allowing the vendor's external server to authenticate back into Salesforce via OAuth to perform data synchronization or trigger automated processes without storing user credentials on the external server.

Continuous monitoring requires an ongoing review of the Connected App's access policies. Under Setup -> Connected Apps OAuth Usage, administrators can view exactly how many active user sessions are currently authorised for each external application. Architects must establish a strict policy for Connected App permissions. For instance, the "Permitted Users" policy should be set to "Admin approved users are pre-authorised," rather than "All users may self-authorise." This ensures that no standard user can accidentally grant an external application access to the company's Salesforce data without explicit administrative approval. Furthermore, the IP Relaxation policy must be evaluated; relaxing IP restrictions for a Connected App allows the vendor's servers to connect from any location, which might bypass corporate VPN or IP whitelist controls, exposing the API to broader internet-based attack vectors.

-- SOQL query to inspect active OAuth tokens and track external user connections
SELECT Id, AppName, UserId, User.Username, DeleteToken, CreateDate FROM OauthTokenType
        

In addition to monitoring active tokens, organisations must schedule regular reviews of the Setup Audit Trail and Event Monitoring logs to detect anomalous behaviour by integration service accounts. If an integration user account assigned to an AppExchange package suddenly begins exporting large volumes of records outside normal business hours, or starts querying objects unrelated to its core function, the security team must have automated transaction security policies in place to alert on or block the transaction. By implementing a lifecycle approach to package governance—spanning rigorous pre-install review, permission containment, data flow verification, and continuous OAuth session auditing—enterprises can confidently harness the innovation of the AppExchange ecosystem while maintaining an absolute lock on their security and compliance boundaries.