Updated June 13, 2015 with additional guidance for Lightning Components
- This article assumes that you are a Developer / Security Professional who understands security best practices.
- Please see the OWASP Secure Coding Practices - Quick Reference Guide for a basic overview of application security concepts.
- Partners are required to follow secure best practices as well as the guidelines described on this page.
- Specific requirements for a each application will vary depending on platform architecture etc.
- The review is a slightly subjective process whereby the organization size, application architecture, data handling, etc. are taken into consideration.
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 will be reviewed. If there are updates since submitting for security review file a case on the partner portal.
- Sharing: Use the “with sharing” keyword when declaring a class to respect sharing rules that apply to current users, unless there is a specific and valid business case to over-ride this which should be marked in false positive document
- Controllers retrieving user-specified objects as well as global classes must always use sharing.
- Classes that modify standard fields must use sharing.
- Classes that modify only custom fields owned by the partner and that are not entry points to the app may use without sharing if they prefer to enforce their own security controls rather than those of the platform.
- CRUD and FLS: 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). More information can be found on the Force.com Secure Cloud Development site under Testing CRUD and FLS Enforcement and in the developerforce CRUD/FLS guide .
- Shield: 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. For more info see Enforcing Encryption
- Triggers: Ensure triggers are bulkified.
- 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.
- Tests: Use System.assert methods as much as possible to prove that code behaves properly. This is key to ensure that the Apex code executes to the expected value or behavior. More information on Best Practices can be found here: http://wiki.developerforce.com/index.php/An_Introduction_to_Apex_Code_Test_Methods
- In order to prevent XSS attacks, your application must properly output encode data for the appropriate rendering operations (e.g. element.innerHTML=…, a.href=...).
Storing Sensitive Information (e.g. credentials or API keys to other applications):
- Ensure that sensitive information is not available to all users in a customer org. This can be achieved by using 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.
For detailed information and guidance on the issues above, please refer to Apex & VisualForce Security Tips
Client (Desktop) and Composite (Hosted) Applications
Make sure you provide us access to a remote testing environment where we can test your client app.
- Implement an Information Security Policy that is periodically reviewed, approved by Senior Management, and communicated to all employees.
Standards & Procedures
- System Configuration
- Application Development
- Application Configuration
- Database Configuration
- Network Configuration (Including Firewall/IDS)
- Patching Process
- Logging Process/Log Review
- Physical Security
- Incident Management Process
- Authentication & Authorization
- Encryption Standard
- 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 3 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)
- Persistent tunnels configured with appropriate ACLs
- Implement an enterprise-wide anti-virus solution with daily updates
- Remote Desktop or Terminal Services Remote Administration should not be exposed to Internet facing connections.
- Reverse Proxy based apps are not allowed on the AppExchange.
- Implement a strong SDLC with security being a core component
- Implement code reviews
- Implement a testing/QA methodology
- Implement a methodology for rolling code to production
- Implement appropriate segregation of duties within the test, development and production environments
- Unless necessary, do not store salesforce.com credentials (leverage the Session IDs)
- If necessary, have a clear rationale and communicate this to salesforce.com
- Implement encryption in transmission and storage (login credentials and salesforce.com customer data)
- Support TLSv1.1 and newer versions
- TLS 1.0 is only supported until July 22, 2017.
- Strong configurations are also required. See https://www.ssllabs.com/ssltest/ for a security rating for your configuration
- Set "secure" flag on session cookies
- Do not store encryption keys in source code
- Implement encryption key management
- 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
- All script and style resources must be loaded via static resources. Do not load resources with a link or script tag. Do not hotlink to js code outside of static resources.
- Implement controls to protect the Salesforce Session ID. Specifically:
- Session ID should always be encrypted in transmission
- 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:
- 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 will allow:
- Ensure that Flash security recommendations are followed as described in the following document:
- 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 (Hosted Applications Only)
- 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
- Wireless Networking
- No wireless in collocation facilities
- WPA2 and wireless IDS implemented at corporate
- E-mail Spam filter
Physical Security (Hosted Applications Only)
- Restrict data center access to authorized personnel
- Maintain physical access logs at the data center
- Implement security cameras, motion detectors and alarms at data centers that are monitored on a 24/7/365 basis
- Implement controls to to prevent the infrastructure against external threats and hazards (fire, earthquake, flooding, etc.)
- Organization default security settings must not be changed. (Password policy, timeout, SSL settings, etc.)
- Packages included in trials must be approved on the AppExchange.
- No unpackaged code or other components may be distributed in trials.
Familiarize yourself with the framework's lifecycle and follow the best practices in the Lightning Component Developer's Guide:
- Review requirements
- If submitting a stand alone component, please include an app container in the DE org so that the component is usable. If the intended app container is the Salesforce1 app, please document this and be sure to create the appropriate tabs so that the component is visible in One.app. Please make it clear how to access and use the app/component after logging into the test org.
- Locker Compliance will be mandatory to submit for the security review. Therefore, the Developer Edition test environment provided for the security review must have Locker Service enabled and the security review will be performed with Locker Service enabled.
- All Lightning Components are required to be running on API v40 or above. More details here.
- App structure
- 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 tha aura:attribute. This is to inform other developers that you these attributes may be dangerous.
- Lightning components or apps should not include or generate <script> tags. Lightning components should not generate <style> tags.
- Methods in helpers or script resources must (ultimately) be called from a renderer or controller of the same component.
- 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.
- Do not use deprecated functions such as newComponent(). Use the latest functions for the framework at the time of submission.
- Do not override browser window or document built-in methods.
- Lightning components must not overlay and allow clickthrough to components from other namespaces.
- 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.
- Lightning Authorization
- Make sure apex controllers and other entry points to the app run 'with sharing'. Do not omit the sharing keyword from any class that accesses data.
- Perform CRUD/FLS checks when returning data to the client or when querying fields in a SOQL query as the platform does not do this for you.
- Respect the Aura rendering lifecycle
- Renderers should not fire events and should not modify component attributes that belong to another component.
- Components should not read or modify DOM elements not belonging to the component.
- Security and code correctness
- 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 unescapedHTML. If they must be passed into these contexts unescape, clearly state that in your components documentation
- 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.
- Be aware of CSRF issues and do not initiate server-side DML operations in an event handler fired automatically by the platform, such as init, or afterRender. Server-side DML operations may only be initiated by user interaction events, such as press.