Salesforce Summaries – Defend Your Castle: An Essential Checklist for Establishing Secure Communities

Share this article...

SalesforceSummaries: a series delivering key insights from Salesforce YouTube videos, to save you time as you keep up to date with the latest technological changes within the Salesforce ecosystem.


This summary goes through the key attacks that can impact Communities and how to protect yourself from them.


Details: ‘Defend Your Castle: An Essential Checklist for Establishing Secure Communities

Presenter: Matt Sherman and Jared Snyder

Time: 20 minutes

Key Terms: SOQL injection, Cross-Site Scripting, Communities, Security


  1. @0.30 — In this session, you will learn about how to prevent attackers from coming after your Community.
  2. @1.20 — You need to consider the following, with regards to creating and maintaining a successful Salesforce Community: Audience, Technology, Engagement, Growth and Security.

You need to think about who the audience is (will it be a public or internal community), you will need to think about what technology will be used in the Community (code or declarative, Classic or Lightning etc), you need to think about how you will engage, if at all, with the community. You will also need to think about how you can measure adoption, understand why people are interacting with the community. And last but not least, you need to consider security. Who should be able to do what and see what records? How can you keep your Community secure?

[email protected] — There are some risks associated with implementing Chatter in your Community. Chatter is a fantastic engagement tool and has some great functionality to prevent ‘attacks’. For example, Member and Content criteria help prevent your Community from offensive language (a reputational risk) and inappropriate content created by spammers or malicious members.

Also, assigned Community moderators can manage malicious posts and block particular users. Malicious posts can be flagged by Community users and so in this way, the Community can self-police itself.

[email protected] — Event Monitoring is a paid for Salesforce add-on that gives you a huge amount of insight into who did what, when. You can leverage Event Monitoring with Transaction Security or a third party app, such as FairWarning.

You can also use Community User Monitoring to see the login history of your Community users. In the logs, you’ll be able to see what browsers and TLS protocol they typically use.

[email protected] — The first line of defence to your Community is the Org-Wide Defaults (OWDs).You can consider OWDs to be like the castle walls. You will want to enable an external sharing model for external Communities.

A key thing that you may want to review is the Community User Visibility. By default, all Community users can see all other users in the Community. This may be great for Chatter collaboration but may be too open for what you want. So you can edit this so as to make Users only see who they should see. More info here.

[email protected] — When writing code for Communities (for example, you may have a Visualforce page or Lightning page that you want to be displayed on a Community page), be very careful with the ‘sharing’ keyword in your controller. ‘With Sharing’ respects the OWDs whilst ‘without sharing’ does not. By default, classes are ‘with sharing’. More info here.

So potentially, ‘without sharing’ can be a huge security issue (although there are some valid reasons why a controller would have ‘without sharing’).

[email protected] — You can use the Security Health Check in Salesforce Setup to identify and fix vulnerabilities. The ‘How is the Health Check Score Calculated’ documentation is here.

[email protected] — There is also a paid add-on as part of Salesforce Shield which will enable you to encrypt data at rest and not just at transmission (it’s important to be aware that there are pros and cons to this, though). More info here.

[email protected] — From a coding perspective, you should refer to the Apex Coding Guidelines.

[email protected] — You need to be aware of SOQL injection attacks. SOQL is the Salesforce version of SQL. It is a query language. A very good eBook resource for learning about SOQL is here.

At a high level, a SOQL injection attack is where one can change the ‘WHERE’ criteria by inputting SOQL into the search criteria itself.

For example, in the below screenshot, the query of ‘Sir’ works as intended.

However, if one inputs SOQL into the search query itself (Sir%’ OR Name LIKE ‘%), then the below results are displayed. This is because the query has been extended by the user; and is showing results that the developer may not have intended the user to see.

This is happening because the query in the underlying code is merely concatenating the input from the user. There is no check in place to query the input query before it is executed at run time.

To resolve this, your query method that executes the SOQL should use verifiable binding instead of merely concatenating. This maintains the structure of the query and it will query the string that the user input literally.

whereclause_records = [SELECT Name, Role__c, Title__c, Age__c FROM Personnel__c WHERE Title__c LIKE :titleSearch];

So let’s try it again with the verifiable binding example, and we can see that no results are returned:

[email protected] — Another security threat that you need to be aware of is cross-site scripting (XSS). This may be more of a concern than the SOQL injection attack because with XSS, there is the risk of data being copied out of the Org. There is a lot of malicious intent one can achieve with XSS attacks with JavaScript.

If you use a <script> tag, then you are responsible for everything that goes on inside of this.

To handle the JavaScript inside a script tag correctly, Salesforce has provided a set of functions to escape potentially insecure strings.

For example, using ‘{!JSINHTMLENCODE(outputText)} ensures protection to ensure the input is taken literally.

[email protected] — So, just to recap, as per below screenshot, this is an example of code that is vulnerable to a SOQL injection.

[email protected] — And the fix is here:

[email protected] — There is another type of XSS, called Cross Site Request Forgery (CSRF). The difference is that, in CSRF, the user is already authenticated.

[email protected] — You should take the Trailhead Trailmix for more information and experience on dealing with these kind of attacks.

By clapping more or less, you can signal to us which stories really stand out.

Andy Hitchings

Salesforce & JavaScript Developer



Save time with our key insights from Salesforce YouTube videos.

Leave a Reply