This would be much beneficial for everyone. This will probably save huge amount of valuable time.

We'd gain momentum with this. We could create value / build apps way faster than now and new ISVs would not be put through the whole frustrating learning process of how to actually deal with this stuff. Even FFLIb hasn't found yet a fast, clean, functional way of doing hits. 

 

Currently it looks like the ISV's life will be further challenged by the new Platform Encryption capability - apex calls will retrieve the value in clear text regardless of what permissions the user has and the ISV will then need to do the right thing in terms of displaying the value or not. 

Ideally classes could be marked with "as user" or "as system" which would govern the context and access levels in which they would run. For many applications (ours anyway) the vast majority of code would be annotated "as user" and then we would be manage what fields and values came back happy in the knowledge we were not breaching security. 

This would be fantastic improvement also (hopefully) from a performance perspective.

The extra performance hit of querying CRUD/FLS permissions in APEX also creates a challenge, in particular for complex logic and multple calls.

If CRUD/FLS could be enforced in the SOQL call, and could be optimised by the platform...

While not providing the requested functionality, there is some progress towards making the implementation of FLS inspection slightly less silly. I figured this would be of interest to the upvoters of this idea.

Summer '16 release notes include:

a = [select Id,Name from Account where id=:a.Id];
Map<String, Object> fieldsToValue = a.getPopulatedFieldsAsMap();

https://releasenotes.docs.salesforce.com/en-us/summer16/release-notes/rn_apex_sobject_getmap.htm

Just a supplement to the my previous comment. Another advantage of Custom Permissions and Permission Sets is that they can be given a meaningful name. e.g. 'Create Invoices' - this Permission Set may involve access to several objects, fields and VF pages. We can then present an ISV customer (the mythical System Admin) with UI we build on a VF page that presents them with a list of permissions sets using terms that they understand in their business context. In effect let us abstract the complexity for non-techie System Admins via Permission Sets. If someone really wants to do something special then they can go under the hood and edit objects and fields directly. 

Its really very simple make Permission Sets and Customer Permissions a legitimate way of honoring FLS/CRUD instead of the ridiculus situation that currently exists.

I'm glad to see ISV kicking up a fuss about this issue. It seems that the Salesforce Security team can't seem to get the heads around the idea that many customers of ISV's do not have System Admins and don't have someone that's going to spend hours tweaking profiles and permissions sets. This is a HUGE issue especially when releasing upgrades and new features. As we can't control Profiles via install scripts we're expecting our customers to spend their precious time clicking permissions on fields across however many objects. THEY ARE NOT SYSTEM ADMINS, they just want the new feature to work

But wait we have permissions sets, right, which can be controlled via install scripts, this seems like a perfect solution. We can release new features and give access via Permission Sets. Even better we now have Custom Permissions which can be applied to Profiles, can be checked in Apex and is an effective way of give access to a new or improved feature that works across a number of objects etc. For example Managed Packaged Widget v2 is released. To work it requires access to 2 new Fields in Object 1 and 3 new Fields in Object 2. Using a push upgrade Widget v1 is upgraded to Widget v2. A post install script applies a Custom Permission to allow Profiles 1 and 2 to access the new features of Widget v2. Perfect, if the (non-existent) System Admin wants to withdraw access to Profile 2 or give Profile 3 access that can adjust the Custom Permission.

HOWEVER, nowhere in the Security Documentation do Permissions Sets get a mention as a way for ISV's to respect FLS/CRUD. The point is a solution already exists on the platform, however nobody in the rest of Salesforce has made the journey to the Security Teams Ivory Tower to inform them of this capability. There's a complete disconnect and fundemental lack of understanding to the customers ISVs serve. 

best comments for testing

In addition to the amount of effort involved in developing a solution for this and figuring out the edge cases where it should and should not apply, I think we need to think about performance as well. Salesforce is the only entity in this case that can assure the describes and accompanying code are running in the most efficient manner and remains in that most efficient manner throughout changes to the platform. Imagine the performance improvement *if* all ISVs were inspecting for fls, poorly, and then Salesforce was able to implement a super fast cached version that we adopted. Maybe we should just skip right to that performance improvement.

Agreed! By default it can be respecting CRUD/FLS and if any developer wants not to follow this they can do so. This will not only make life of ISVs easy but will also make any custom inhouse application more secure (which never go through any Security Review). 

This is very important for ISV currently .We have good libraries to manage this internally but I cant imagine if this happens out of box ,i will save lot of time .

This is HUGE. It is not only a problem for ISVs, but for every admin. Hand-in-hand, Apex only runs under system mode and Visual Flow only runs under CRUD/FLS mode. There are certainly instances in which I want to run operations in Visual FLOW under system mode, while other operations are fine running in user mode. Likewise, obviously, we should be able to run Apex either in system or user permission mode. This is a high-level shortcoming/pain point for EVERYONE whether they realize it or not. Imagine my surprise when I discovered SKUID commands and record visibility didn't follow user permissions!

This is core functionality that SF should have in place - give us the option which context to run in. PLEASE.

This is HUGE. It is not only a problem for ISVs, but for every admin. Hand-in-hand, Apex only runs under system mode and Visual Flow only runs under CRUD/FLS mode. There are certainly instances in which I want to run operations in Visual FLOW under system mode, while other operations are fine running in user mode. Likewise, obviously, we should be able to run Apex either in system or user permission mode. This is a high-level shortcoming/pain point for EVERYONE whether they realize it or not. Imagine my surprise when I discovered SKUID commands and record visibility didn't follow user permissions!

This is core functionality that SF should have in place - give us the option which context to run in. PLEASE.

When I first heard about this obligation being given to the developers I thought it was a joke.  I thought the entire platform giving us custom SQL(SOQL), DML methods, and database structure was because they were providing the structure/security.

This Idea really needs to be supported, it's such a simple concept.  Salesforce has already gone through all the work of defining the user/profile system, might as well give us a quick and easy way to hook into it.

I think so too Apex should be secure by "default".