Securing your force.com app
Building an app on force.com is great. But when it comes to developing a secure force.com app its a bit different thing.
Following are the guide lines, tips and tricks that you can follow to ease your app to pass Force.com security review .
- Parameter Tampering Issue.
This happens when you are trying to send some value from visualforce page and the value is being used throughout the controller. When this being used with any query it may result into database tempering.
Example :
String vid = ApexPages.currentPage().getParameters().get(‘id’);
account acc =[select id,name from account where id=:vid limit 1];
Solution:
account acc =[select id,name from account where id=:ApexPages.currentPage().getParameters().get(‘id’) limit 1];
- Second Order SOQL and SOSL Injection.
SOQL injection involves taking user-supplied input and using thosevalues in a dynamic SOQL query. If the input is not validated, it may include SOQL commands that effectively modify the SOQL statement and trickthe application into performing unintended commands.
Solution 1.: Avoid using dynamic SOQL/SOSL queries
Solution 2:
Example :
Folio__cfo=[select id,name from Folio__c where
Transaction__r.Id=:sr.Transaction__r.Id AND id!=null LIMIT 1];
Can be changed into
Folio__cfo=[select id,name from Folio__c where Transaction__r.Id=:String.escapeSingleQuotes(sr.Transaction__r.Id) AND id!=null LIMIT 1];
- Queries with No Where or No Limit Clause
Apex has governor limits in place that limits the number of records that can be retrieved through a SOQL query. This issue says SOQLqueries in the apex code that does not have a WHERE clause nor uses the LIMIT clause to restrict the number of records retrieved.
Solution: Apply Limit , if not possible to use limits use Where clause.
The Where clause can be a null check on id field
accq=[select id,name from account where id!=null];
- Sharing with controller
By default Apex have capability to read and update all data and doesn’t cares about FLS,OWD or profile permissions. We must take care of all these from a developer’s perspective.If no sharing setting is defined on the controller this may give a security issue.
Solution:
Use “public with sharing class className”
- FLS Create/FLS Partial Create /FLS Update/ FLS Partial Update:
While creating/inserting/updating a record the Apex code must check if the user have sufficient privileges to insert/update the record.
Example:
OrderPayment__c op = new OrderPayment__c();
Payment_Amount__c=grandtotal;
Collection_Date__c=Date.valueOf(System.now());
Collection__c=true;
insert op;
Solution :
OrderPayment__c op = new OrderPayment__c();
Payment_Amount__c=grandtotal;
Collection_Date__c=Date.valueOf(System.now());
Collection__c=true;
if(Schema.sObjectType.OrderPayment__c.fields.Payment_Amount__c.isCreateable() && Schema.sObjectType.OrderPayment__c.fields.Collection_Date__c.isCreateable() && Schema.sObjectType.OrderPayment__c.fields.Collection__c.isCreateable() ){
insert op;
}
In Case of update
if(Schema.sObjectType.OrderPayment__c.fields.Payment_Amount__c.isUpdateable() && Schema.sObjectType.OrderPayment__c.fields.Collection_Date__c.isUpdateable() && Schema.sObjectType.OrderPayment__c.fields.Collection__c.isUpdateable() ){
Update op;
}
- Test_Methods_With_No_Assert :
Proper assert statements are advised, at least 10 to 20 in a single test class.
- For Store XSS (Cross Site Scripting )Issue
About: Cross-site scripting is a vulnerability that occurs when an attacker can insert unauthorized JavaScript, VBScript, HTML, or other active content into a web page viewed by other users.
This issue raised when controllervariable are being used in JavaScript / JQuery .
Example:
Public class mycontroller{
String myval{get;set;}
Public mycontroller(){
Myval=’Hello Page Loaded’;
}
}
//On page
<Script>
Varscriptvar = ‘{!myval}’;
Alert(scriptvar);
</script>
POSSIBLE SOLUTION:
Varscriptvar = ‘{!JSENCODE(myvar)}’;
Happy Secure Coding 🙂
