Surveys and business analysts (and often your father, while combing his mustache sitting on his rocking chair adjusting his reading glasses) consistently warn you that security reasons are the biggest obstacles in the path of a full-fledged adoption of cloud computing, especially amongst the enterprise customers. Salesforce has become an integral part of majority enterprises and it has become an utmost necessity to be convinced that the huge amount of data revealed to it is absolutely safe.
For a fact, Salesforce does use some of the most advanced technologies for combating the cyber crime and ensuring stringent Internet security policies. When you access the site using a supported web browser the Secure Socket Layer or the SSL technology safeguards your information using the concept of authentication as well as data encryption.
Salesforce makes use of a multi-layered approach that constantly protects the critical data by monitoring and enhancing the application and meets the demands of the security needed in the domain of cloud. However, a large part of security lies in the hands of the firm using it as well. Salesforce also plays a huge role in structuring the security and providing various tools to meets the safety needs of the organization.
Salesforce basically deals with the following security approaches and they are as follows:
- Organization Security
- Object Security
- Record Security
- Field Security
- Folder Security
However, in this post, we will basically talk about the CRUD (Create Read Update Delete) and the FLS (Field Level Security) approach.
The CRUD Structure And The FLS Security
The CRUD (Create-Read-Update-Delete) structure gives an uptight security. The Create, Read, Update and Delete these object permissions determine what are the type of actions the users can perform on any of the records of the objects to which they have access. This “Create” “Read” “Update” “Delete” settings are applied at the profile level and this setting is used to restrict the type of actions that the users are able to perform on each and every type of custom and standard objects. The object permissions i.e “View All” And “Modify All” give the users access to all the object’s records not depending on record level access settings.
Coming onto FLS or (Field Level Security)
Field Level Security or FLS gives you the provision to restrict particular individuals from accessing super sensitive and confidential information that are located in the records that they can see. FLS security is configured similar to CRUD but it allows the administrators to be able to pre-define the profiles that can see as well as write to most of the fields of the custom and standard objects.
Record-level access i.e known as Sharing in Salesforce determines how and which records a user can access and see for a particular object, which is done using the following tools:
- Organization-wide Defaults
- Role Hierarchy
- Teams
- Manual Sharing
- Sharing Rules
- Programmatic Sharing
However, the Salesforce Lightning components do not automatically enforce the CRUD or the FLS when you reference the objects or retrieve the objects from an Apex controller. CRUD or FLS both are enforced when using the “@AuraEnabled” notation.
Automatic CRUD And FLS Enforcement In VisualForce
While rendering the VisualForce pages, when the developer references the SObjects and SObject fields directly in the VisualForce page the platform will automatically enforce CRUD and FLS approach. To cite an example, if a user is with no FLS visibility to the Contact phone field object, then to see the page underneath the phone numbers would be removed from the table automatically.
01 <apex:page standardController="Account">
02 <apex:pageBlock title="Contacts">
03 <apex:dataTable value="{!account.Contacts}" var="contact" cellPadding="4" border="1">
04 <apex:column>
05 <apex:facet name="header">Name</apex:facet>
06 {!contact.Name}
07 </apex:column>
08 <apex:column>
09 <apex:facet name="header">Phone</apex:facet>
10 {!contact.Phone}
11 </apex:column>
12 </apex:dataTable>
13 </apex:pageBlock>
14</apex:page>
VisualForce also caters towards removing the fields for which the users don’t have FLS visibility while rendering the edit pages. All the apex: input Field tags will be treated and rendered as read-only elements for all those fields that are set to read-only via FLS. However making use of the other input tags like apex:inputText or apex:inputTextArea with SObject fields point out to VisualForce that the fields must not be treated as SObject fields and thereby restricts the platform to automatically enforce FLS.
01<apex:page standardController="Contact" recordSetVar="contacts">
02 <apex:pageBlock title="Contacts">
03 <apex:form>
04 <apex:dataTable value="{!contacts}" var="contact" cellPadding="4" border="1">
05 <apex:column>
06 <apex:facet name="header">Name</apex:facet>
07 <apex:inputField value="{!contact.LastName}" />
08 </apex:column>
09 <apex:column>
10 <apex:facet name="header">Phone</apex:facet>
11 <apex:inputField value="{!contact.Phone}" />
12 </apex:column>
13 </apex:dataTable>
14 <apex:commandButton action="{!save}" value="Save" />
15 </apex:form>
16 </apex:pageBlock>
17 </apex:page>
Manual CRUD And FLS Enforcement In VisualForce
The field describes calls that are available in Apex are also available in VisualForce through the $ObjectType element. Enforcement in Apex controllers is usually more preferred for scalability and general robustness reasons, but there are situations where manual enforcement in VisualForce is useful.
1 <!-- This would normally bypass automatic FLS enforcement for accessibility-->
2 <apex:outputText value="{!contactName}"
3
rendered="{!$ObjectType.Contact.fields.Name.Accessible}" />
1 <!-- This would normally bypass automatic FLS enforcement for updates-->
2 <apex:inputText value="{!contactEmail}"
3
rendered="{!$ObjectType.Contact.fields.Email.Updateable}" />
1 <!-- This isn't a particularly strong way to prevent access to a controller method.
2 The below should only be viewed as an example
3 -->
4 <apex:commandButton action="{!CustomDelete}"
5 rendered="{!$ObjectType.Contact.Deletable}" />
1 <!-- stringToBecomeNewContactEmail is a generic string type so automatic FLS
2 enforcement is not available
3 -->
4 <apex:inputText value="{!stringToBecomeNewContactEmail}"
5
rendered="{!$ObjectType.Contact.fields.Email.Createable}" />
In this blog, I have discussed mainly the CRUD and FLS approach in VisualForce highlighting the Salesforce security. But it is a vast topic and needs more in-depth knowledge and digging. However, Salesforce has become an integral part of major organizations and has taken all steps to safeguard the highly imperative data and it continues to evolve.
Don’t forget to Contact Us for any query 🙂
Reference: certifiedondemand.com, developer.salesforce.com, docs.google.com
Pratyush Kumar
