AppExchange Security Requirements Checklist

The purpose of this checklist is to help ensure a successful submission to the AppExchange market. If a candidate does not meet the relevant requirements detailed in this checklist, the candidate can be returned to the submitter for revision and resubmission. Specific requirements vary for each application depending on platform architecture etc. Use your best judgement to check the requirements that apply to your submission. The review is a slightly subjective process whereby the organization size, application architecture, data handling, etc. are taken into consideration.

Before Using this Checklist

Any enterprise that wishes to submit a candidate to the AppExchange must implement the practices detailed in the OWASP Secure Coding Practices - Quick Reference Guide. It is available through the Open Web Application Security Project site.

Who Should Use this Checklist 

Any enterprise that wishes to submit a candidate Force.com app or a composite bundle for the AppExchange must satisfy the relevant items in this checklist. See Requirements for Composite Submissions (below) if you are submitting a bundle of website, mobile app, and desktop client software. This checklist is written for an audience of developer and security professional who understand security best practices. Partners are required to follow secure best practices as well as the guidelines described in this document.

False Positive Documents

In some cases, candidate code includes known violations of the requirements in this checklist. Provide a false-positive document if there is a specific and valid business case to bypass a given requirement. False-positive docs can be simple text or pdf format.

Requirements for Force.com Apps

The following requirements apply to native Force.com apps. See Requirements for Composite Submissions (below) if you are submitting a bundle of website, mobile app, and desktop client software.

Force.com Code

Required: all Force.com code on the AppExchange must be in managed packages. 

Once a package version is submitted for security review only that package version is reviewed. If there are updates after submission for security review, you must submit a case on the Partner Community for the revised version.

Apex Code

If your submission includes Apex code, it must comply with the conventions described below: 

Required: the with sharing keyword Use the with sharing keyword when declaring a class to respect sharing rules that apply to current users. 
  • All controllers that retrieve user-specified objects, as well as global classes, must use the with sharing keyword. 
  • All classes that modify standard fields must use the with sharing keyword. 
Classes that only modify custom fields owned by the submitter and that are not entry points to the app may use the without sharing keyword if the submitter prefers to enforce their own security controls in place of the platform’s security controls.

Required: correct CRUD and FLS settings 
Enforce and respect FLS (Field Level Security) and CRUD (Create, Read, Update, Delete) settings configured by your customer's org administrator when accessing fields that you do not own (standard fields). See the Force.com Secure Cloud Development site and the CRUD/FLS guide for more information.

Required: the Shield encryption model Enforce the encryption model put in by shield by using Schema.sObjectType.Contact.fields.Phone.isEncrypted() and checking whether or not the user has the permission PermissionsViewEncryptedData. See Enforcing Encryption for more information.

Required: no Cross-Site Request Forgery (CSRF) vulnerabilities Do not perform Data Manipulation Language (DML) operations in page actions or in any action that runs automatically (Aura init() or afterRender(), JavaScript submitting forms on page load). Server-side DML operations may only be initiated by user interaction events, such as press(). If DML is required within a Visualforce page load, select the Require CSRF Protection on GET requests option, as described by Visualforce help documentation

Required: notify user if package installation accesses metadata If your package accesses metadata during installation or update, or contains a custom setup interface that accesses metadata, you must notify the user. The notice should let customers know that your package has the ability to modify the subscriber org’s metadata. For installs that access metadata, notify the user in the description of your package. 

See Also: the Salesforce training module - Secure Coding Cross Site Request Forgery.

VisualForce Code

If your submission includes VisualForce pages, it must comply with the conventions described below: 

Required: correctly escape string types in mergefields In visualforce mergefields, properly escape all string types based on the rendering context: In html text nodes, no escaping is necessary. Within script tags or JavaScript event handlers, mergefields should be wrapped with JSENCODE() and then quoted. 
  • Do not place mergefields that are of string type within style tags. 
Required: no mergefields in client-side macros Do not place visualforce mergefields within client-side micro templates (for example, angular templates). Rather, assign the quoted mergefield to a JavaScript variable within a script tag and then pass the variable to the compiled template or to the client side controller.

Custom Javascript and HTML

If your submission includes custom JavaScript and HTML, it must comply with the conventions described below: 

Required: precautions against Cross-Site Scripting (XSS)
In order to prevent XSS attacks, your application must properly output encode data for the appropriate rendering operations (element.innerHTML=…, a.href=...). 

Required: partner JavaScript can only execute within the context of Visualforce
JavaScript that is part of partner offerings should not execute within the context of the Salesforce.com application. Any OnClickJavascript event in custom buttons or weblinks is grounds for failure. 

Required: all script and style resources must be loaded through static resources 
  • Do not load resources dynamically with a link or script tag.
  • Do not hotlink to JavaScript code outside of static resources. 
Required: provide your un-minified source file 
To aid in reviewing custom JavaScript, include un-minified source files when submitting for the security review corresponding to all minified files in static resources. Please give the unminified files the same name (except .min), for scanning purposes. Do not combine unminified and minified files together. Also include source files for all languages that transpile to JavaScript in your code (JSX). Auxiliary source files should be provided in static resources. 

Required: Static resources should be free of known vulnerabilities Ensure that all libraries included in static resources are free of known vulnerabilities. Known vulnerabilities can be found by searching Common Vulnerabilities and Exposures (CVE) databases or using security tools such as Snyk or RetireJS.

Storing Sensitive Information

If your submission stores sensitive information such as credentials or API keys to other applications, it must comply with the conventions described below: 

Required: restricted visibility of sensitive information
Ensure that sensitive information is not available to all users in a customer org. Use a Custom Settings or Custom Metadata Types in “Protected” mode and creating a Visualforce page for authorized users to update information. The previously stored data should not be displayed back to the user on this page (define a null getter and also mark the variable as private and transient). Another option is to implement Apex Crypto and store the encryption key in a protected custom setting. For more information see the Secure Cloud Development entry for Storing Secrets.

Lightning Components

If your submission includes Lightning Experience components, it must comply with the conventions described below: 

Required: an app container for standalone components If your submission is a stand alone component, include an app container in the Developer Edition org so that the component is usable. If the intended app container is the Salesforce1 app, document this and be sure to create the appropriate tabs so that the component is visible in One.app. Be sure to explain how to access and use the app/component after logging into the test org. See the Creating Apps section of the Lightning Components Developer Guide for instructions. 

Required: enable Locker Service & CSP Locker Compliance and Content Security Policy are mandatory for security review submissions. Therefore, the Developer Edition test environment submitted for the security review must have Locker Service and CSP enabled. The security review is performed with Locker Service and CSP enabled. 

Required: LockerService Support (API v40 or newer) 
All Lightning Components are required to run on API v40 or above. See the Release Notes for more information. 

Required: your un-minified source file
To aid in reviewing custom JavaScript, include un-minified source files when submitting for the security review corresponding to all minified files in static resources. Please give the unminified files the same name (except .min), for scanning purposes. Do not combine unminified and minified files together. Also include source files for all languages that transpile to JavaScript in your code (e.g. JSX). Auxiliary source files should be provided in static resources.

App Structure Retirements

Required: Apex requirements
All submissions that include interactions with the Apex server must comply with the Apex requirements detailed in the Apex Code section. 

Required: document dangerous aura:attribute attributes
When global component attributes or app events flow into possible HTML rendering contexts, it must be documented in the documentation for the component, or the description attribute of the aura:attribute. This is to inform other developers that these attributes may be dangerous. 

Required: no generated <script> tags
Lightning components or apps cannot include or generate <script> tags. Lightning components cannot generate <style> tags. 

Required: no inline JavaScript
Avoid inline JavaScript with the exception of event handlers that call controller methods. They cannot call methods of the helper or of a loaded script resource. 

Required: proper handling of helper and script methods
Methods in helpers or script resources must (ultimately) be called from a renderer or controller of the same component. 

Required: proper loading of resources 
All script and style resources must be loaded with an ltng:require component and must be stored in static resources. Do not load resources with a link or script tag. Do not hotlink to js code outside of static resources. 

Required: no deprecated functions
Do not use deprecated functions such as newComponent(). Use the latest functions for the framework at the time of submission. 

Required: no overrides of browser window or document built-in methods 

Required: no unsafe JavaScript constructs
Do not use JavaScript constructs that execute arbitrary code such as eval() or Function.prototype.constructor(). Code should be written to work with a CSP policy that bans eval() as well as unsafe-inline, regardless of the environment in which the code is intended to be served. Required: no overlays or click-throughs to components from other namespaces 

Required: the uniminified and untranspiled sources
If submitting Lightning Container Components to the AppExchange, you must include unminified and untranspiled sources as a part of your review. Reviews without readable code will be sent back.

Aura Rendering Lifecycle Requirements

Be sure to follow the rules detailed in the Create a Custom Renderer in the Lightning Component Developer Guide. 

Required: a renderer must not fire events and must not modify component attributes that belong to another component. 

Required: proper context switching 
When re-entering the framework from outside the framework's lifecycle (for example asynchronous JavaScript such as setTimeout), obtain a reference to an action through $A.getCallback() so that your code can properly run in the context of your component. 

Required: use CSS animations
When running animations, CSS animations are recommended. For JavaScript animations, please check that the DOM element exists so that your code does not throw exceptions should your component be unrendered while the animation is occurring. 

Required: components must not read or modify DOM elements that belong to other components.

Security and Code Correctness Requirements

Required: correctly handle sensitive attribute-values in expression language
Sanitize all assignments to hrefs, svg xlinkhrefs, and other URLs to ensure that they do not contain "javascript:". iframe srcdoc and iframe src are also sensitive and must be treated similarly. For a full list of sensitive attribute values see the html5 security cheatsheet 

Required: correctly handle user data that will be assigned to window.location
Do not assign user data to window.location without first verifying it does not contain a 'javascript:' pseudo scheme and has the correct host. If you are using third party libraries, audit them to ensure they also follow this requirement 

Required: treat all public and global component attributes as untrusted (e.g. under the controller of an attacker), and sanitize values prior to using them in a renderer or other dangerous context such as an aura:unescapedHTML. If they must be passed into these contexts unescape, clearly state that in your components documentation 

Required: in a renderer, avoid use of innerHTML and other html rendering functions when possible. We currently do not provide escaping libraries to make these functions safe.

Requirements for Composite Submissions

The following requirements apply to ‘composite’ submissions which include code for an integrated website, a mobile app, and a desktop client. Make sure you provide Salesforce access to a remote testing environment for testing your client app.

Host/Platform Security

The following requirements apply to the servers hosting your platform: 
  • Disable unnecessary services on key servers (web application, database, etc.) 
  • Run up-to-date versions of all services on key servers. 
  • Implement robust patch management Remove/Rename default accounts and change default passwords 
  • Securely hash all passwords with a unique, random salt 
  • Create unique usernames for all users 
  • Implement a robust password policy (organizational and application) 
    • Minimum 8 characters 
    • Combination (2 out of 4) of numbers, letters (lower and upper) and special characters 
    • Enable lock outs for bad attempts (3-5) Enable password expiration (90-180 days) 
    • Enable password history (don’t allow reuse of last 5 passwords) 
    • Passwords should not be sent to third parties (Google analytics, fullstory) 
  • Implement system logging and enforce periodic review of logs 
  • Implement host based firewalls on critical systems 
  • Implement secure remote access (VPN – SSHv2, SSL, IPSEC, or AES) 
  • Use persistent tunnels configured with appropriate ACLs 
  • Implement an enterprise-wide anti-virus solution with regular updates 
  • Remote Desktop or Terminal Services Remote Administration should not be exposed to Internet facing connections

Application Security

The following apply to client apps submitted as part of the composite bundle: 
  • You must implement the practices detailed in the OWASP Secure Coding Practices - Quick Reference Guide
  • No reverse-proxy based apps are allowed on the AppExchange 
  • Do not store salesforce.com credentials, use OAuth 2.0 instead 
  • Implement encryption for data in motion and for data at rest (login credentials and salesforce.com customer data) 
  • Prevent username enumeration 
    • Do not give different feedback to the user if the account does or does not exist in password reset pages 
  • Use CAPTCHA's or other defenses against automated login attempts 
  • Do not allow login CSRF (forced login) Avoid Dynamic SQL 
    • If Using Dynamic SQL, prepare appropriate rationale for salesforce.com 
    • Implement appropriate compensating controls 
  • Implement appropriate input validation and URL cleansing to prevent SQL Injection and Cross-Site Scripting (XSS) attacks 
  • Implement controls to protect the Salesforce Session ID. Specifically: 
    • Session ID should not be sent to third parties (Example: Google Analytics) 
    • Validate that the connection is being requested from a valid Salesforce server. Below is the regex to validate legitimate SFDC SOAP servers:

1

^https://[^/?]+\\.(sales|visual\\.)force\\.com/services/(S|s)(O|o)(A|a)(P|p)/(u|c)/.*


To summarize the above regex, it ensures that the URL starts with ‘https://’, followed by a character other than ‘/ ‘ or '?' for 1 or more times, followed by a ‘.’, followed by ‘sales’ or ‘visual.’, followed by ‘force.com/services/SOAP/’, followed by ‘u’ or ‘c’, followed by ‘/’. This allows the following: 
  • https://*.salesforce.com/services/SOAP/u/ 
  • https://*.salesforce.com/services/SOAP/c/ 
  • https://*.my.salesforce.com/services/SOAP/u/ 
  • https://*.my.salesforce.com/services/SOAP/c/ 
  • https://*.visual.force.com/services/SOAP/u/ 
  • https://*.visual.force.com/services/SOAP/c/ 
  • Ensure that Flash security recommendations are followed as described in the following document.

Best Practices

The following suggestions are provided to help improve the awareness of our partners of the different ways to assure and improve security.

Enterprise Information Security Policies 

Implement an enterprise Information Security Policy that is periodically reviewed, updated, approved by senior management, and communicated to all employees.

Enterprise Standards and Procedures 

Implement enterprise standards and procedures for the following: 
  • Application Development 
    • A strong SDLC with security as a core component 
      • Include code reviews 
      • Include a testing/QA methodology 
      • Include a methodology for rolling code to production 
    • Implement appropriate segregation of duties within the test, development and production environments 
  • Application Configuration 
  • System Configuration 
  • Database Configuration 
  • Network Configuration (Including Firewall/IDS) 
  • Patching Process Logging Process/Log Review 
  • Physical Security 
  • Incident Management Process 
  • Authentication and Authorization 
  • Encryption Standard

Operational Security 

Implement enterprise standards and procedures for the following: 
  • Actively monitor your network 
  • Implement and periodically test 
  • Disaster Recovery and Business Continuity Plans 
  • Implement an Employee Training and Security Awareness Program 
  • Implement Encryption Key and Privileged User Password Rotation 
  • Implement a robust change management process which includes documentation and approval of all changes 
  • Perform security review of third-party organizations

Network Security for Specifically for Hosted Applications

Be sure the facility and environment for hosted applications includes the following: 
  • A Stateful Packet Inspection Firewall 
  • Segregation of Web/Application and database servers 
  • Network IDS/IPS implemented (required if critical Salesforce data is stored in external servers) 
  • Log aggregation, alerting and daily review for key network devices, application and database servers 
  • No wireless connectivity enabled in co-located facilities 
  • WPA2 and wireless IDS implemented at corporate facilities 
  • E-mail Spam filter

Physical Security Specifically for Hosted Applications

Be sure the real-world facility which hosts your applications includes the following: 
  • Restricted data-center access to authorized personnel 
  • Maintained physical access-logs at the data center 
  • Operational security cameras, motion detectors and alarms at data centers that are monitored on a 24/7/365 basis 
  • Preventative measures to protect the infrastructure against external threats and hazards such as fire, earthquake, flooding, etc.

Trial Templates

If you provide trial templates to your customers, be sure to follow these best practices: 
  • Organization default security settings must not be changed. (Password policy, timeout, SSL settings, etc.) during a trial as compared to a production release. 
  • Packages included in trials must be approved on the AppExchange. 
  • No unpackaged code or other components may be distributed in trials.

See Also

The following links to Salesforce documents provide helpful explanations and instructions for developing secure code for our platform.