I have a without sharing sharing class to insert Users and assign permission sets.

Am using WITH SECURITY ENFORCED in select query

Am facing an error: Insufficient permissions: secure query included inaccessible field

Is it necessary to include WITH SECURITY ENFORCED in without sharing class?

  • You can not say it is necessary or not, it is totally based on the business case. You can remove that if needed. Mar 19, 2021 at 9:30
  • If I remove that am facing PMD issue. My scenario is a user who doesn't have access on user object can create an user via another app. So if I run my class as without sharing then I would be able to achieve this right
    – Prathyusha
    Mar 19, 2021 at 9:35
  • 1
    that is just a warning if you are doing this for ISV then you need to provide the false positive report, and yes will be able to do with without sharing class Mar 19, 2021 at 10:00

2 Answers 2


Just to be clear, these mechanisms control different things:

  • WITH SECURITY ENFORCED: enables field- and object-level security permissions checking. These are the object and field permissions that you normally set in the profile / permission sets.
  • WITH SHARING: enables record level security checking. Record security is controlled by owd, sharing rules, manual sharing etc.

So, if your class is WITHOUT SHARING, it means that your code won't enforce record level security. If, in addition, you use WITH SECURITY ENFORCED in your queries, it means object & field level security will be checked in your query, on top of record security checks.

Said that, you can omit WITH SECURITY ENFORCED, if your use case doesn't need you to check for those permissions.


If your business case requires you to give a user a UI to perform an action that their sharing rules don't permit, the best practice would be:

  • The Apex controller (for VF/Aura/LWC/etc) should still be in with sharing mode.
  • Any SOQL/DML that would contravene sharing rules should be refactored to a utility class that is without sharing.
  • You should ensure the business case for calling that utility class to escalate privileges is well-documented and referenced in the code comments.
  • Even if your front-end code enforces some of the rules of this business case (e.g. validating that they should indeed have permission to do this, validating form inputs), your Apex controller should re-check those rules again before escalating privileges. This protects you against malicious users attempting to bypass front-end validations.
  • If this code does not pass an automated scanner that's OK because you know the business rules are being followed. If this is an ISV context though, your justification for the false positive should still explain what you are doing to ensure you do not violate the wishes of the subscriber in escalating permissions. For example you might have a setup page where the subscriber admin grants consent to allow privilege escalation in a specific defined circumstance.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .