Upload
salesforce-developers
View
2.027
Download
2
Embed Size (px)
Citation preview
Secure Salesforce: Lightning Component Best Practices Secure best practices
Sergey Gorbaty SMTS Product Security [email protected] @ser_gor
Robert Sussland SMTS Product Security [email protected]
Safe harbor statement under the Private Securities Litigation Reform Act of 1995:
This presentation may contain forward-looking statements that involve risks, uncertainties, and assumptions. If any such uncertainties materialize or if any of the assumptions proves incorrect, the results of salesforce.com, inc. could differ materially from the results expressed or implied by the forward-looking statements we make. All statements other than statements of historical fact could be deemed forward-looking, including any projections of product or service availability, subscriber growth, earnings, revenues, or other financial items and any statements regarding strategies or plans of management for future operations, statements of belief, any statements concerning new, planned, or upgraded services or technology developments and customer contracts or use of our services.
The risks and uncertainties referred to above include – but are not limited to – risks associated with developing and delivering new functionality for our service, new products and services, our new business model, our past operating losses, possible fluctuations in our operating results and rate of growth, interruptions or delays in our Web hosting, breach of our security measures, the outcome of any litigation, risks associated with completed and any possible mergers and acquisitions, the immature market in which we operate, our relatively limited operating history, our ability to expand, retain, and motivate our employees and manage our growth, new releases of our service and successful customer deployment, our limited history reselling non-salesforce.com products, and utilization and selling to larger enterprise customers. Further information on potential factors that could affect the financial results of salesforce.com, inc. is included in our annual report on Form 10-K for the most recent fiscal year and in our quarterly report on Form 10-Q for the most recent fiscal quarter. These documents and others containing important disclosures are available on the SEC Filings section of the Investor Information section of our Web site.
Any unreleased services or features referenced in this or other presentations, press releases or public statements are not currently available and may not be delivered on time or at all. Customers who purchase our services should make the purchase decisions based upon features that are currently available. Salesforce.com, inc. assumes no obligation and does not intend to update these forward-looking statements.
Safe Harbor
• Client Side Security
• Security Model and Dangers
• Lightning Domain Separation
• Playing Safe Within Your Locker
• Content Security Policy
• Escaping, Rendering, External Scripts
• Server Side Security
• Apex Controllers, Aura Methods
• CRUD, FLS
• Summary
Agenda
• Lightning applications built using components
• Components come from your org, from Salesforce and from AppExchange
• All non-Salesforce authored Lightning components run from the Lightning Domain*
• Same Origin Policy Browser Security Model
• Many components will be rendered from the same Lightning Domain
• Security risks come from JavaScript and not from Lightning design
• JavaScript from different code bases runs on the same domain
• Can access everything
Security Model and Dangers
• Lightning domains are used for all things Lightning
• Including partner applications, components
• Data and metadata fetching
• Domain separation will improve over time
• Each component needs to play safe within its locker to avoid breakage
Lightning Domain Separation
Do not:
• Send user data to 3rd party external domains
• Clobber Aura built-in methods
• Implement component RPC yourself
• Trigger DML operations from init()
• Modify DOM in the controller
• Fire events from renderer
• Use 3rd party MVC
Playing Safe Within Your Locker
Do:
• Call your own controller’s @AuraEnabled methods
• Modify only your own component’s DOM
• Use <aura:method> to define component actions
• Use events for communication
• COMPONENT type events for internal events
• APPLICATION type events should be treated as ‘navigation’
• Practice JavaScript secure coding best practices
Playing Safe Within Your Locker (Cont’d.)
• Common ground rules for safe-by-default communication
• XHR, websockets can only connect to the application origin
• Script sources can only be loaded from the application origin, e.g. from static resources
• All components are subject to CSP
• Additional rules are enforced at the security review
• No eval(), inline JavaScript, dynamic <script> creation, innerHTML based rendering…
• Latest details posted at
• https://developer.salesforce.com/page/Lightning_Security
Content Security Policy
• Avoid href assignment via document.location.href
• Use relative URL with ‘/’ and encodeURI
• String attributes need to be escaped if rendered outside of Lightning rendering
• Avoid rendering using <unescapedHTML>, v.body, innerHTML
• Instead of element.innerHTML = ‘<div class=‘ + class + ‘”>’ + name + ‘</div>’;
• Use element.className = class; element.innerText = name;
• Public attribute of String data must be escaped before assignment to v.body
• For additional escaping functions check Aura.Utils.SecureFilters
Component Data Rendering Tips
• Use unambiguous class sharing definition
• with sharing
• without sharing
• Assume any @AuraEnabled method is global == web service
• Components may call it out of order
• Additional checks are needed due to various user levels
Apex Controllers, Aura Methods
• Apex runs in a system mode, will return all data for every user
• Lighting Components do not have automatic CRUD enforcement
• Each @AuraEnabled method that returns data must perform checks
• Do not assume user has access to all fields
• Checks must be performed on all objects
• Checks allow best user experience when access is limited
• Documentation
• https://developer.salesforce.com/page/Testing_CRUD_and_FLS_Enforcement
CRUD, FLS
• User input and 3rd party data needs to be rendered safely, use escaping
• Never assume user has access to anything, perform proper checks in Apex
• Use JavaScript defensively and do not access other components’ DOM directly
Summary
Secure Salesforce at Dreamforce 2015
10 DevZone Talks and 2 Lighting Zone Talks covering all aspects of Security on the Salesforce Platform
Visit our booth in the DevZone with any security questions
Check out the schedule and details at http://bit.ly/DF15Sec
Admin-related security questions?
Join us for coffee in the Admin Zone Security Cafe