ISVforce Guide
Summer '26 (API version 67.0)
Spring '26 (API version 66.0)
Winter '26 (API version 65.0)
Summer '25 (API version 64.0)
Spring '25 (API version 63.0)
Winter '25 (API version 62.0)
Summer '24 (API version 61.0)
Spring '24 (API version 60.0)
Winter '24 (API version 59.0)
Summer '23 (API version 58.0)
Spring '23 (API version 57.0)
Winter '23 (API version 56.0)
Summer '22 (API version 55.0)
Spring '22 (API version 54.0)
Winter '22 (API version 53.0)
Summer '21 (API version 52.0)
Spring '21 (API version 51.0)
Winter '21 (API version 50.0)
Summer '20 (API version 49.0)
Spring '20 (API version 48.0)
Winter '20 (API version 47.0)
Summer '19 (API version 46.0)
Spring '19 (API version 45.0)
Winter '19 (API version 44.0)
Summer '18 (API version 43.0)
Spring '18 (API version 42.0)
Winter '18 (API version 41.0)
Summer '17 (API version 40.0)
Spring '17 (API version 39.0)
Winter '17 (API version 38.0)
Summer '16 (API version 37.0)
Spring '16 (API version 36.0)
Winter '16 (API version 35.0)
Summer '15 (API version 34.0)
Spring '15 (API version 33.0)
Winter '15 (API version 32.0)
Spring '14 (API version 30.0)
Grow Your AppExchange Business
Create a Secure Solution
Loading JavaScript Files from Third-Party Endpoints
Loading Third-Party CSS in Lightning Components
Using CSS Outside Components
Running JavaScript in the Salesforce Domain
Exposing Secret Data When Debugging
Storing Sensitive Data Insecurely
Using Software That Has Known Vulnerabilities
Using Sample Code in Production
Bypassing Object-Level and Field-Level Access Settings
Bypassing Sharing Rules in Apex
SOQL Injection Due to Insecure Database Query Construction
Cross-Site Request Forgery
Open Redirects
Lightning LockerService Disabled
Insufficient Escaping in Lightning Components
Asynchronous Code in Components
Connected Apps
Glossary
Newer Version Available
Prevent Common Violations of Secure Coding Guidelines
The AppExchange security review assesses a solution’s vulnerability to the most common
security attacks. To pass the review, a solution can’t violate secure coding guidelines. Only
solutions that pass the review can be publicly distributed on AppExchange. Increase the likelihood
that your solution passes. Learn which violations appear the most in reviewed solutions, why they
pose security risks, and how to avoid them in your code.
-
Loading JavaScript Files from Third-Party Endpoints
Avoid dynamically loading third-party JavaScript files from content delivery networks (CDNs). Instead, load the code from the static resources folder of your package. -
Loading Third-Party CSS in Lightning Components
Include cascading style sheets (CSS) and other resources in static resources rather than loading from a third party. -
Using CSS Outside Components
The Salesforce Platform tries to ensure that each namespace is an isolated sandbox, but isolation can’t always be guaranteed. Where a namespace isolation breach occurs, one component can steal clicks from another component, or otherwise interfere with another component’s intended use. To prevent this type of abuse, don’t use CSS directives known to be incompatible with style isolation in your components. -
Running JavaScript in the Salesforce Domain
JavaScript code from multiple vendors can run in the same origin. To prevent code interference, vendor JavaScript code is sandboxed. Don’t attempt to break out of a sandbox or run code outside your origin. Use Visualforce, Aura, or Lightning Web Components, which run in the proper origin. -
Exposing Secret Data When Debugging
In production environments, logging secret data with debug statements is a security vulnerability. Don’t log secret data, sensitive information, passwords, keys, or stack traces in production environments. Redact the data or omit it from the logs. -
Storing Sensitive Data Insecurely
Follow enterprise security standards when you export data from the Salesforce Platform and when you store secret data in the platform. -
Using Software That Has Known Vulnerabilities
Using software that has documented common vulnerabilities and exposures (CVE) related to your use cases is a security vulnerability. If your solution has known vulnerabilities, test and deploy security patches as soon as they’re available. If your solution uses software that has CVE-documented vulnerabilities unrelated to your use cases, prepare false positive documentation. -
Using Sample Code in Production
Only use sample code as an educational tool in preparation for developing your own application. When building your production code, always write the code yourself. Avoid copying code from sources that you don’t directly control. -
Bypassing Object-Level and Field-Level Access Settings
Design your solutions to enforce the org’s create, read, update, and delete (CRUD) and field-level security (FLS) settings on standard and custom objects. -
Bypassing Sharing Rules in Apex
Respect profile-based permissions, field-level security, sharing rules, and org-wide defaults in your Apex code. -
SOQL Injection Due to Insecure Database Query Construction
To prevent Salesforce Object Query Language (SOQL) injection, use bind variables and input sanitation. -
Cross-Site Request Forgery
A cross-site request forgery (CSRF) is an attack that forces an end user to execute unwanted actions during their authenticated web application session. To protect against CSRF, use confirmationTokenRequired, or trigger state changes with user actions. -
Open Redirects
An open redirect occurs when an application dynamically redirects to a user-controlled parameter value without any validation. Prevent open redirects by using hardcoded redirects. -
Lightning LockerService Disabled
Lightning LockerService is a critical security feature for Lightning code. It provides component isolation that allows code from many sources to execute and interact using safe, standard APIs and event mechanisms. Enable Lightning Locker for AppExchange packages that contain Lightning components or applications. -
Insufficient Escaping in Lightning Components
Each component in a bundle is responsible for sanitizing the input provided to it by parent components, apps, or in URL parameters. -
Asynchronous Code in Components
Hackers can manipulate the timing of asynchronous code to produce malicious results. To preserve current execution context, wrap asynchronous function calls or batch actions into a single request.