Salesforce Security Review

When we are creating any application to be published on the AppExchange, the role of the application security becomes indispensable. A Salesforce security expert looks at the application’s source code before an application is published. Additionally, they also check the external integrations to ensure proper security standards are followed. This is referred to as a security review. Once the application clears the security review test with zero security findings, only then it can be released onto the AppExchange. The security review also equips the partners and developers to meet the enterprise security rules that most of their future customers will ask for.

Below is the list of queries for which the salesforce experts check the source code:

1.Reflected XSS
2.SOQL SOSL Injection
3.Stored XSS
4.FLS Update
5.CRUD Delete
6.FLS Create
8.Hardcoding References To Static Resources
9.Multiple Trigger On same sObject
10.Queries With No Where Or Limit Clause
11.Multiple Forms In Visualforce Page
12.Hardcoding Ids
13.Hardcoding Of Trigger New
14.SOSL SOQL Statements Inside Loops
15.Test Methods With No Assert
16.Lightning API Version
17.Client DOM Stored Code Injection
18.Client DOM Code Injection
19.Client DOM Stored XSS
20.Client DOM XSS
21.URL Redirection Attack
24.Client Overly Permissive Message Posting
25.DML Statements Inside Loops
26.Async Future Method Inside Loops
27.Bulkify Apex Methods Using Collections In Methods

All the queries mentioned above have different meaning belonging to some standard group. Please see below to see some detailed information for some of them.


XSS refers to “cross-site scripting”. This weakness occurs when dynamically generated web pages display data that are not validated, filtered, and encoded. This is how a user input allows a hacker to insert malicious scripts into the web page. This can be further used to execute scripting code which will appear as if it came from the site’s server to the computer of a user who used the site. This may be a false positive if the datatype is safe to render unescaped.

FLS Issues:

The FLS refers to “Field Level Security”. This query examines whether the fields that are being used in the Apex code are accessible to the logged in user or not. This is true that we can have permission sets for each profile but, the apex code is free to use the fields even if it has no rights to access it. A simple step for this is to check if the user is allowed to access or create or update a specific field belonging to the object or not.

Below are the checks that can be applied before a field is accessed or a new value is set to it:
– Schema.sObjectType.CustomObject__c.fields.FieldName.isAccessible()
– Schema.sObjectType.CustomObject__c.fields.FieldName.isUpdateable()
– Schema.sObjectType.CustomObject__c.fields.FieldName.isCreatable()

When we perform any insert/update operation on any object, add below lines before DML operations:
– CustomObject__c.sObjectType.getDescribe().isUpdateable()
– CustomObject__c.sObjectType.getDescribe().isCreatable()

Multiple Trigger On same sObject:

Per salesforce documentation, to have multiple triggers on the same object is not considered a best practice. This rule recognizes the presence of multiple Apex triggers associated with the same sObject. This is so because it is possible to have repetitive code or logic performed in the different triggers. Considering various triggers may be a way to enhance and improve the code. The fact is, there is no guarantee the order in which multiple triggers on the same sObject will execute. So, to resolve security errors belonging to this group, move all the triggers’ code to single trigger and per best practice, move all the logic to an apex class and name it as TriggerHandler.