While fixing security issues for a customer, I came across a very interesting and powerful security API from Salesforce i.e. Force.com ESAPI. As per Google code description this API
“ESAPI (The OWASP Enterprise Security API) is a free, open source, web application security control library that makes it easier for programmers to write lower-risk applications. The ESAPI libraries are designed to make it easier for programmers to retrofit security into existing applications or build a solid foundation for new development.
The Force.com implementation of the ESAPI library is designed and customized for the security needs of the Force.com platform.”
Going forward with this post, I am assuming you comfortable with guidelines set by Salesforce to get security review cleared for App Exchange. If you are not, its in general a good idea for every Apex/Visualforce developer to go thru this link for more idea about Salesforce Security compliance. If you follow these rules from very starting, life will be beautiful later on near release time
What really is Force.com ESAPI ?
On a high level ESAPI provides following modules, for more details on each please refer the getting started guide : http://code.google.com/p/force-dot-com-esapi/wiki/GettingStarted
- Input Validation : Validators available for Credit Card, Numbers, Dates, HTTP requests. More details in Apex Doc here.
- Output Encoding : Visualforce equivalents of JSENCODE, HTMLENCODE etc in Apex. More details in this apex doc.
- Access Control for Force.com objects (CRUD/FLS and Sharing) :
- First, who want to understand what is CRUD/FLS in relation with Salesforce Security requirements, please go thru this link “Enforcing CRUD and FLS”.
- This module is my favorite and does a good job in saving you from writing a lot of Apex code for ensuring CRUD/FLS compliance. More details about APIs in this Apex doc
- This module gives you APIs to do CRUD operations as per CRUD/FLS permissions of logged-in/current USER. This is important because by default apex runs in GOD MODE, i.e. by passing the CRUD/FLS (even if WITH SHARING is with class declaration). So rather doing direct insert contacts or update contacts, one can go for
- insertAsUser(sObject someObjs, List<String> fieldsToSet)
- updateAsUser(Map<ID, sObject> objMap, List<String> fieldsToUpdate)
- This module also provides facility to plug and play sharing behavior, one can set SHARING to either WITH, WITHOUT or INHERIT for all the CRUD operations. for ex.
- Similarly, one can set ALL OR NONE behavior for records i.e. If you are doing a CRUD operation on an Sobject with 10 fields, out of those 10 current user is permitted for only 5, then should the operation be a success or not. ex :
Some challenges with this project !
This project is making heavy use of Apex describe information, so its prone to hit governor limits on some occasions, more details here : http://code.google.com/p/force-dot-com-esapi/issues/detail?id=3
Force.com community - Lets take ESAPI to the next level !
Force.com ESAPI is awesome, I love the way its architected, i.e.
- Follows the thumb rule of loose coupling though out.
- Clear contract definition of each sub component via interfaces and abstract classes.
- Awesome java style apex docs, that clearly describe the usage of each API. This rich Apex doc, is result of those Java style apex comments only
What’s required next from us(force.com community) is to contribute more into this project, via
- Blog, tweet and discuss about this project to increase the awareness.
- Create detailed code samples for various scenarios per module, specially the CRUD/FLS one. Try adding them to the Google Code WIKI or let others know via your blogs.
- Joining as contributor to this project, add various new API’s like upsertAsUser and various other validation routines.
- Test, report and fix the issues.
- and much more.
Looking forward for your views.