[SalesForce] Enforce Field-Level Security Permissions for SOQL Queries WITH SECURITY_ENFORCED (Confused )

What is the need of WITH SECURITY_ENFORCED?

Only benefit is minimal development experience with security and to applications where graceful degradation on permissions errors isn’t required.

If field is hidden then it will give the error on UI or while saving the class?

Use the WITH SECURITY_ENFORCED clause to enable checking for field- and object-level security permissions on SOQL SELECT queries, including subqueries and cross-object relationships.

So after using this with SEcurity_ENforce isCreateable,isEditable,isDeleteable will be deprecated????

Best Answer

Currently if you include a field in a SQOL query that a user doesn't have access, the field is returned and can be used by the code, thus exposing the data to someone that should not have access to it.

This new clause is a blunt way to ensure your code isn't provided access to fields that an admin may have specifically restricted access to via the profile. It does this by throwing an exception if there are any fields in the query that the context user doesn't have access to.

This feature is tailored to Apex developers who have minimal development experience with security and to applications where graceful degradation on permissions errors isn’t required.

You may want to use the isAccessible or similar fields to provide a better experience to your users, but that requires more logic and error handling. I highly doubt they'd be deprecated as they give the developer much more control when handling FLS.

If a field is hidden, the exception will bubble up to whatever the calling code is.
e.g. If it's a controller on a page, and you have the pageMessages on your VF page, then the exception will be shown there.

Related Topic