How safe are your Lightning Components? Join us and learn about the foundations required for a secure application built on Lightning. We'll cover common misconceptions around field-level security, CRUD, content security policy (CSP), as well as other common mistakes with Lightning. You'll walk away with all the best practices for hardening your application and keeping your data secure.

1. Secure Salesforce:
Lightning Component Best Practices
Secure best practices
​ Sergey Gorbaty
​ SMTS Product Security
​ sergey.gorbaty@salesforce.com
​ @ser_gor
​
​ Robert Sussland
​ SMTS Product Security
​ rsussland@salesforce.com
​

2. ​ 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

3. Sergey Gorbaty
SMTS Product Security, Salesforce

4. Robert Sussland
SMTS Product Security, Salesforce

5. • 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

6. Client Side Security

7. • 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

8. • 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

9. 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

10. 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.)

11. • 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

12. • 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

13. Demo

14. Server Side Security

15. • 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

16. • 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

17. Demo

18. Summary

19. • 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

20. Thank youThank you

21. 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

22. Secure Salesforce Sesssions
​ Common Secure Coding Mistakes
​ Rachel Black and Alejandro Raigon Munoz
​ THURSDAY
​ 5:00pm in Moscone West 2006
​ Chimera: External Integration Security
​ Tim Bach and Travis Safford
​ FRIDAY
​ 10:00am in Moscone West 2009