Guidelines for building secure apps on force.com

1. FORCE.COM
SECURITY
BUILDING SECURE APPS ON FORCE.COM PLATFORM

2. OVERVIEW
• What is Security?
• Is force.com platform not Secure?!
• What is Security Review?
• Common Security Vulnerabilities
• Why do these Vulnerabilities occur?
• How to fix these Vulnerabilities?

3. WHAT IS SECURITY?
• Prevent unauthorized external access of data and logic
• Prevent unauthorized internal access of data and logic
• Principle of Least Privilege
“Users should only have access to the minimum amount of information required
to accomplish their duties”
“Users’ ability to take advantage of excess privilege purposefully or accidentally
should be minimized”

4. IS FORCE.COM NOT SECURE?!
• All standard apps built on force.com are secure & respect all data access and
security settings
• Because force.com is a platform, it gives some power & flexibility to the
developers; some of the security controls are released to developers
• So, when building custom apps its developers responsibility to take care of
some security aspects

5. WHAT IS SECURITY REVIEW?!
• Salesforce security experts look at application’s source code to ensure proper
security standards are followed
• Is security only important for AppExchange apps?
• Security is more significant for AppExchange apps, but the guidelines should
be followed all the time.

6. COMMON SECURITY VULNERABILITIES
• Not respecting CRUD
• Not respecting FLS
• Not respecting Sharing Settings
• SOQL Injection
• XSS (Cross-Site Scripting)
• CSRF (Cross-Site Request Forgery)
• Open Redirects
• Insecure Remote Resource Interactions

7. NOT RESPECTING CRUD!
• Occurs when an application violates CRUD settings on Profiles/ Permission sets
• Execution Context:
User Context: Enforces CRUD
System Context: Ignores CRUD
• Apex runs in system context, which means it ignores CRUD settings
Users can query the data even if there is no READ permission
Users can Create records even if there is no CREATE permission
Users can Update records even if there is no EDIT permission
Users can Delete records even if there is no DELETE permission
• VF Pages respect CRUD, but not always true!

8. CRUD IN VF PAGE
• VF code respects CRUD:
• VF code does not respect CRUD:
• VF Pages with JS Remoting do not respect CRUD

9. MAKING APEX RESPECT CRUD
• Before query or DML use:

10. NOT RESPECTING FLS!
• Occurs when an application violates Field Level Security settings
• Execution Context:
User Context: Enforces FLS
System Context: Ignores FLS
• Apex runs in system context, which means it ignores FLS settings
Users can see data of a field which is hidden
Users can update/ create data of a field which is hidden/ read-only
• VF Pages respect FLS, but not always true!

11. FLS IN VF PAGE
• VF code respects FLS:
• VF code does not respect FLS:
• VF pages with JS Remoting do not respect FLS

12. MAKING APEX RESPECT FLS
• Before query or DML use:

13. NOT RESPECTING SHARING SETTINGS!
• Occurs when the application violates Sharing Settings
• Execution Context:
User Context: Enforces Sharing Settings
System Context: Ignores Sharing Settings
• Apex runs in system context, which means it ignores Sharing settings
Users can see the records which are not shared with them

14. SHARING SETTINGS SCENARIOS!
• Apex does not Respect Sharing Settings
• Apex Respects Sharing Settings

15. FIXING SHARING ISSUE!
• Use “with sharing” key word for every class
• You should have a strong reason if you are not using “with sharing” key word

16. SOQL INJECTION!
• SOQL injection is the vulnerability which allows attackers to modify queries at
run time, thereby getting access to unauthorized data
• Occurs when user input starts behaving like code instead of text!
• This happens when user input is directly inserted into a dynamic query without
validating or escaping
• Users can access fields or data that a developer did not intend to reveal!

17. PREVENTING SOQL INJECTION!
• Use static queries wherever possible
• Escaping Single Quotes:
- This adds a “” before every single quote
- This prevents inputs from being treated as code and treat them as strings

18. XSS – (CROSS SITE SCRIPTING)!
• XSS is the vulnerability which allows attackers to insert unauthorized
javascript, VBScript, HTML or other active content into a web page.
• When the web page loads the malicious code executes, which may lead to a
wide range to security issues.
• Occurs due to poor separation between code and data contexts.
• Occurs when user input is treated as code!
- Data starts acting as code!

19. TYPES OF XSS!
• Reflected XSS
- Malicious script is injected as url parameter
- Malicious script is injected into a text field
• Stored XSS
- Malicious script is stored in data base
- Malicious script executes when data is retrieved and displayed on a web
page

20. SOME IMPACTS OF XSS!
• Malicious script can be used to steal sensitive data
• Malicious script can be used to deface a web page and impact a company’s
reputation
• Attackers can steal a user’s session and make unauthorized requests
• Attackers can show a pop up which looks legitimate, but could download a
virus
• Malicious script can be used to log key strokes and steal user credentials
• Many more………

21. PREVENTING XSS!
• Avoid use of “escape=false” with VF tags
• Use “JSENCODE()” in javascript context
• Use “HTMLENCODE()” in HTML context
• Use “JSINHTMLENCODE()” when both javascript and html are involved

22. CSRF (CROSS SITE REQUEST FORGERY)
• CSRF is vulnerability where a malicious application causes user to perform an
unwanted action on a trusted site
• User is tricked to click on a URL
- which looks legitimate
- but performs unwanted action
• Can lead to unwanted data updates or deletes

23. PREVENTING CSRF
• Avoid any state changing operations in “apex:page” tag
• Avoid DML actions which create, update or delete data in “apex:page” tag

24. OPEN REDIRECTS
• Open Redirects is a vulnerability where a users is redirected to an
unauthorized site
• Also know as “Arbitrary Redirect”
• Occurs when values that are controlled by the users determine where the app
redirects

25. OPEN REDIRECTS

26. OPEN REDIRECTS

27. PREVENTING OPEN REDIRECTS
• Allow only local redirects, i.e. allow only partial urls
• Whitelist all allowed external domains & validate before redirection

28. REMOTE RESOURCE INTERACTION
• Avoid using CDNs
- Risk is not that big, but we want to achieve 100% security
- some malicious code could steal data, redirection to malicious sites etc
• Use static resource for storing all third-party libraries and scripts

29. • Not respecting CRUD
• Not respecting FLS
• Not respecting Sharing Settings
• SOQL Injection
• XSS (Cross-Site Scripting)
• CSRF (Cross-Site Request Forgery)
• Open Redirects
• Insecure Remote Resource Interactions