LaceySnr.com - Salesforce Development Posts by Matt Lacey

Apex, FLS, CRUD and You: The Most Important Idea on the IdeaExchange

Posted: 2016-02-05

I've discussed the Salesforce.com security review in multiple posts on this blog, and as I've stated before I do believe it to be a good thing. My main gripe with the security review isn't actually a problem with the review process itself, but one of the requirements. That requirement is this:

All ISV developers must enforce CRUD and FLS in their Apex code.

The thing to realise here is that the requirement itself isn't the cause of the pain, rather it's a readily apparent symptom.

The Real Cause

The real cause of the pain here is that the platform doesn't enforce FLS and CRUD in Apex. I'm going to say that again, as it's often something misunderstood by those new to the platform.

The platform does not enforce FLS and CRUD in Apex.

There are occasions where the platform does help you out, if you use <apex:inputField> and <apex:outputField> in Visualforce pages then the platform has your back. Visualforce Remote Objects also enforce security for you.

What, Why Not?

Code is error prone. Bugs can arise in any number of ways, from logic errors on the part of the developer to bad input data causing code to behave in unexpected ways (but you check your input values are valid, right?). Code that depends on objects and fields from the database is liable to break if those fields aren't available, which may be the case if, for example, a security layer has prevented access to them.

It's a hard problem to deal with in a managed package, and it's even harder to deal with it at a platform level, so it should come as no surprise that it's not in the platform. When Apex was first introduced adding automatic security would have been a huge challenge. Of course, that challenge is larger now but I believe it's outweighed by the level of overhead, issues and security risks caused by developers rolling things their own way.

What About with sharing?

Sharing rules control access to records, not to objects or fields, so typically omiting some records when passing control to code isn't going to cause anything like the issues caused by missing objects or fields. Toggling the enforcement of sharing rules by without/with sharing has nothing to do with the CRUD and FLS permissions granted to a user.

So What Do We Do?

Well first off, if you're creating a managed package for the AppExchange then you simply can not get around the requirement to perform FLS and CRUD checks. There are libraries out there such as the FinancialForce.com fflib_SecurityUtils that make this task somewhat easier.

Now, to the point of this post. As you should already know, Salesforce provides an IdeaExchange where you can submit ideas for new features/enhancements that you'd like to see on the platform, and David Eposito has submitted what is possibly the most important idea on the site: Enforce CRUD and FLS in Apex. I have no doubt that implementing this idea will be hard, but the work it will save and the risks it will mitigate are immesurable.

Please visit the idea and vote it up!