Process completed with exit code 1.

Process completed with exit code 127.

Detect classes declared without explicit sharing mode if DML methods are used. This forces the developer to take access restrictions into account before modifying objects. ApexSharingViolations (Priority: 3, Ruleset: Security) https://pmd.github.io/pmd-6.55.0/pmd_rules_apex_security.html#apexsharingviolations

The rule validates you are checking for access permissions before a SOQL/SOSL/DML operation. Since Apex runs by default in system mode not having proper permissions checks results in escalation of privilege and may produce runtime errors. This check forces you to handle such scenarios. Since Winter '23 (API Version 56) you can enforce user mode for database operations by using `WITH USER_MODE` in SOQL. This makes Apex to respect Field-level security (FLS) and object permissions of the running user. When using user mode, no violation is reported by this rule. By default, the rule allows access checks can be performed using system Apex provisions such as `DescribeSObjectResult.isAccessible/Createable/etc.`, the SOQL `WITH SECURITY_ENFORCED` clause, or using the open source [Force.com ESAPI](https://github.com/forcedotcom/force-dot-com-esapi) class library. Because it is common to use authorization facades to assist with this task, the rule also allows configuration of regular expression-based patterns for the methods used to authorize each type of CRUD operation. These pattern are configured via the following properties: * `createAuthMethodPattern`/`createAuthMethodTypeParamIndex` - a pattern for the method used for create authorization and an optional 0-based index of the parameter passed to that method that denotes the `SObjectType` being authorized for create. * `readAuthMethodPattern`/`readAuthMethodTypeParamIndex` - a pattern for the method used for read authorization and an optional 0-based index of the parameter passed to that method that denotes the `SObjectType` being authorized for read. * `updateAuthMethodPattern`/`updateAuthMethodTypeParamIndex` - a pattern for the method used for update authorization and an optional 0-based index of the parameter passed to that method that denotes the `SObjectType` being authorized for update. * `deleteAuthMethodPattern`/`deleteAuthMethodTypeParamIndex` - a pattern for the method used for delete authorization and an optional 0-based index of the parameter passed to that method that denotes the `SObjectType` being authorized for delete. * `undeleteAuthMethodPattern`/`undeleteAuthMethodTypeParamIndex` - a pattern for the method used for undelete authorization and an optional 0-based index of the parameter passed to that method that denotes the `SObjectType` being authorized for undelete. * `mergeAuthMethodPattern`/`mergeAuthMethodTypeParamIndex` - a pattern for the method used for merge authorization and an optional 0-based index of the parameter passed to that method that denotes the `SObjectType` being authorized for merge. The following example shows how the rule can be configured for the [sirono-common](https://github.com/SCWells72/sirono-common) [`AuthorizationUtil`](https://github.com/SCWells72/sirono-common#authorization-utilities) class: ```xml <rule ref="category/apex/security.xml/ApexCRUDViolation" message="Validate CRUD permission before SOQL/DML operation"> <priority>3</priority> <properties> <property name="createAuthMethodPattern" value="AuthorizationUtil\.(is|assert)(Createable|Upsertable)"/> <property name="readAuthMethodPattern" value="AuthorizationUtil\.(is|assert)Accessible"/> <property name="updateAuthMethodPattern" value="AuthorizationUtil\.(is|assert)(Updateable|Upsertable)"/> <property name="deleteAuthMethodPattern" value="AuthorizationUtil\.(is|assert)Deletable"/> <property name="undeleteAuthMethodPattern" value="AuthorizationUtil\.(is|assert)Undeletable"/> <property name="mergeAuthMethodPattern" value="AuthorizationUtil\.(is|assert)Mergeable"/> </properties> </rule> ``` Note: This rule will produce false positives for VF getter methods. In VF getters the access permission check happens automatically and is not needed explicitly. However, the rule can't reliably determine whether a getter is a VF getter or not and reports a violation in any case. In such cases, the violation should be [suppressed](pmd_userdocs_suppressing_warnings.html). ApexCRUDViolation (Priority

The rule validates you are checking for access permissions before a SOQL/SOSL/DML operation. Since Apex runs by default in system mode not having proper permissions checks results in escalation of privilege and may produce runtime errors. This check forces you to handle such scenarios. Since Winter '23 (API Version 56) you can enforce user mode for database operations by using `WITH USER_MODE` in SOQL. This makes Apex to respect Field-level security (FLS) and object permissions of the running user. When using user mode, no violation is reported by this rule. By default, the rule allows access checks can be performed using system Apex provisions such as `DescribeSObjectResult.isAccessible/Createable/etc.`, the SOQL `WITH SECURITY_ENFORCED` clause, or using the open source [Force.com ESAPI](https://github.com/forcedotcom/force-dot-com-esapi) class library. Because it is common to use authorization facades to assist with this task, the rule also allows configuration of regular expression-based patterns for the methods used to authorize each type of CRUD operation. These pattern are configured via the following properties: * `createAuthMethodPattern`/`createAuthMethodTypeParamIndex` - a pattern for the method used for create authorization and an optional 0-based index of the parameter passed to that method that denotes the `SObjectType` being authorized for create. * `readAuthMethodPattern`/`readAuthMethodTypeParamIndex` - a pattern for the method used for read authorization and an optional 0-based index of the parameter passed to that method that denotes the `SObjectType` being authorized for read. * `updateAuthMethodPattern`/`updateAuthMethodTypeParamIndex` - a pattern for the method used for update authorization and an optional 0-based index of the parameter passed to that method that denotes the `SObjectType` being authorized for update. * `deleteAuthMethodPattern`/`deleteAuthMethodTypeParamIndex` - a pattern for the method used for delete authorization and an optional 0-based index of the parameter passed to that method that denotes the `SObjectType` being authorized for delete. * `undeleteAuthMethodPattern`/`undeleteAuthMethodTypeParamIndex` - a pattern for the method used for undelete authorization and an optional 0-based index of the parameter passed to that method that denotes the `SObjectType` being authorized for undelete. * `mergeAuthMethodPattern`/`mergeAuthMethodTypeParamIndex` - a pattern for the method used for merge authorization and an optional 0-based index of the parameter passed to that method that denotes the `SObjectType` being authorized for merge. The following example shows how the rule can be configured for the [sirono-common](https://github.com/SCWells72/sirono-common) [`AuthorizationUtil`](https://github.com/SCWells72/sirono-common#authorization-utilities) class: ```xml <rule ref="category/apex/security.xml/ApexCRUDViolation" message="Validate CRUD permission before SOQL/DML operation"> <priority>3</priority> <properties> <property name="createAuthMethodPattern" value="AuthorizationUtil\.(is|assert)(Createable|Upsertable)"/> <property name="readAuthMethodPattern" value="AuthorizationUtil\.(is|assert)Accessible"/> <property name="updateAuthMethodPattern" value="AuthorizationUtil\.(is|assert)(Updateable|Upsertable)"/> <property name="deleteAuthMethodPattern" value="AuthorizationUtil\.(is|assert)Deletable"/> <property name="undeleteAuthMethodPattern" value="AuthorizationUtil\.(is|assert)Undeletable"/> <property name="mergeAuthMethodPattern" value="AuthorizationUtil\.(is|assert)Mergeable"/> </properties> </rule> ``` Note: This rule will produce false positives for VF getter methods. In VF getters the access permission check happens automatically and is not needed explicitly. However, the rule can't reliably determine whether a getter is a VF getter or not and reports a violation in any case. In such cases, the violation should be [suppressed](pmd_userdocs_suppressing_warnings.html). ApexCRUDViolation (Priority

The rule validates you are checking for access permissions before a SOQL/SOSL/DML operation. Since Apex runs by default in system mode not having proper permissions checks results in escalation of privilege and may produce runtime errors. This check forces you to handle such scenarios. Since Winter '23 (API Version 56) you can enforce user mode for database operations by using `WITH USER_MODE` in SOQL. This makes Apex to respect Field-level security (FLS) and object permissions of the running user. When using user mode, no violation is reported by this rule. By default, the rule allows access checks can be performed using system Apex provisions such as `DescribeSObjectResult.isAccessible/Createable/etc.`, the SOQL `WITH SECURITY_ENFORCED` clause, or using the open source [Force.com ESAPI](https://github.com/forcedotcom/force-dot-com-esapi) class library. Because it is common to use authorization facades to assist with this task, the rule also allows configuration of regular expression-based patterns for the methods used to authorize each type of CRUD operation. These pattern are configured via the following properties: * `createAuthMethodPattern`/`createAuthMethodTypeParamIndex` - a pattern for the method used for create authorization and an optional 0-based index of the parameter passed to that method that denotes the `SObjectType` being authorized for create. * `readAuthMethodPattern`/`readAuthMethodTypeParamIndex` - a pattern for the method used for read authorization and an optional 0-based index of the parameter passed to that method that denotes the `SObjectType` being authorized for read. * `updateAuthMethodPattern`/`updateAuthMethodTypeParamIndex` - a pattern for the method used for update authorization and an optional 0-based index of the parameter passed to that method that denotes the `SObjectType` being authorized for update. * `deleteAuthMethodPattern`/`deleteAuthMethodTypeParamIndex` - a pattern for the method used for delete authorization and an optional 0-based index of the parameter passed to that method that denotes the `SObjectType` being authorized for delete. * `undeleteAuthMethodPattern`/`undeleteAuthMethodTypeParamIndex` - a pattern for the method used for undelete authorization and an optional 0-based index of the parameter passed to that method that denotes the `SObjectType` being authorized for undelete. * `mergeAuthMethodPattern`/`mergeAuthMethodTypeParamIndex` - a pattern for the method used for merge authorization and an optional 0-based index of the parameter passed to that method that denotes the `SObjectType` being authorized for merge. The following example shows how the rule can be configured for the [sirono-common](https://github.com/SCWells72/sirono-common) [`AuthorizationUtil`](https://github.com/SCWells72/sirono-common#authorization-utilities) class: ```xml <rule ref="category/apex/security.xml/ApexCRUDViolation" message="Validate CRUD permission before SOQL/DML operation"> <priority>3</priority> <properties> <property name="createAuthMethodPattern" value="AuthorizationUtil\.(is|assert)(Createable|Upsertable)"/> <property name="readAuthMethodPattern" value="AuthorizationUtil\.(is|assert)Accessible"/> <property name="updateAuthMethodPattern" value="AuthorizationUtil\.(is|assert)(Updateable|Upsertable)"/> <property name="deleteAuthMethodPattern" value="AuthorizationUtil\.(is|assert)Deletable"/> <property name="undeleteAuthMethodPattern" value="AuthorizationUtil\.(is|assert)Undeletable"/> <property name="mergeAuthMethodPattern" value="AuthorizationUtil\.(is|assert)Mergeable"/> </properties> </rule> ``` Note: This rule will produce false positives for VF getter methods. In VF getters the access permission check happens automatically and is not needed explicitly. However, the rule can't reliably determine whether a getter is a VF getter or not and reports a violation in any case. In such cases, the violation should be [suppressed](pmd_userdocs_suppressing_warnings.html). ApexCRUDViolation (Priority

The rule validates you are checking for access permissions before a SOQL/SOSL/DML operation. Since Apex runs by default in system mode not having proper permissions checks results in escalation of privilege and may produce runtime errors. This check forces you to handle such scenarios. Since Winter '23 (API Version 56) you can enforce user mode for database operations by using `WITH USER_MODE` in SOQL. This makes Apex to respect Field-level security (FLS) and object permissions of the running user. When using user mode, no violation is reported by this rule. By default, the rule allows access checks can be performed using system Apex provisions such as `DescribeSObjectResult.isAccessible/Createable/etc.`, the SOQL `WITH SECURITY_ENFORCED` clause, or using the open source [Force.com ESAPI](https://github.com/forcedotcom/force-dot-com-esapi) class library. Because it is common to use authorization facades to assist with this task, the rule also allows configuration of regular expression-based patterns for the methods used to authorize each type of CRUD operation. These pattern are configured via the following properties: * `createAuthMethodPattern`/`createAuthMethodTypeParamIndex` - a pattern for the method used for create authorization and an optional 0-based index of the parameter passed to that method that denotes the `SObjectType` being authorized for create. * `readAuthMethodPattern`/`readAuthMethodTypeParamIndex` - a pattern for the method used for read authorization and an optional 0-based index of the parameter passed to that method that denotes the `SObjectType` being authorized for read. * `updateAuthMethodPattern`/`updateAuthMethodTypeParamIndex` - a pattern for the method used for update authorization and an optional 0-based index of the parameter passed to that method that denotes the `SObjectType` being authorized for update. * `deleteAuthMethodPattern`/`deleteAuthMethodTypeParamIndex` - a pattern for the method used for delete authorization and an optional 0-based index of the parameter passed to that method that denotes the `SObjectType` being authorized for delete. * `undeleteAuthMethodPattern`/`undeleteAuthMethodTypeParamIndex` - a pattern for the method used for undelete authorization and an optional 0-based index of the parameter passed to that method that denotes the `SObjectType` being authorized for undelete. * `mergeAuthMethodPattern`/`mergeAuthMethodTypeParamIndex` - a pattern for the method used for merge authorization and an optional 0-based index of the parameter passed to that method that denotes the `SObjectType` being authorized for merge. The following example shows how the rule can be configured for the [sirono-common](https://github.com/SCWells72/sirono-common) [`AuthorizationUtil`](https://github.com/SCWells72/sirono-common#authorization-utilities) class: ```xml <rule ref="category/apex/security.xml/ApexCRUDViolation" message="Validate CRUD permission before SOQL/DML operation"> <priority>3</priority> <properties> <property name="createAuthMethodPattern" value="AuthorizationUtil\.(is|assert)(Createable|Upsertable)"/> <property name="readAuthMethodPattern" value="AuthorizationUtil\.(is|assert)Accessible"/> <property name="updateAuthMethodPattern" value="AuthorizationUtil\.(is|assert)(Updateable|Upsertable)"/> <property name="deleteAuthMethodPattern" value="AuthorizationUtil\.(is|assert)Deletable"/> <property name="undeleteAuthMethodPattern" value="AuthorizationUtil\.(is|assert)Undeletable"/> <property name="mergeAuthMethodPattern" value="AuthorizationUtil\.(is|assert)Mergeable"/> </properties> </rule> ``` Note: This rule will produce false positives for VF getter methods. In VF getters the access permission check happens automatically and is not needed explicitly. However, the rule can't reliably determine whether a getter is a VF getter or not and reports a violation in any case. In such cases, the violation should be [suppressed](pmd_userdocs_suppressing_warnings.html). ApexCRUDViolation (Priority

The rule validates you are checking for access permissions before a SOQL/SOSL/DML operation. Since Apex runs by default in system mode not having proper permissions checks results in escalation of privilege and may produce runtime errors. This check forces you to handle such scenarios. Since Winter '23 (API Version 56) you can enforce user mode for database operations by using `WITH USER_MODE` in SOQL. This makes Apex to respect Field-level security (FLS) and object permissions of the running user. When using user mode, no violation is reported by this rule. By default, the rule allows access checks can be performed using system Apex provisions such as `DescribeSObjectResult.isAccessible/Createable/etc.`, the SOQL `WITH SECURITY_ENFORCED` clause, or using the open source [Force.com ESAPI](https://github.com/forcedotcom/force-dot-com-esapi) class library. Because it is common to use authorization facades to assist with this task, the rule also allows configuration of regular expression-based patterns for the methods used to authorize each type of CRUD operation. These pattern are configured via the following properties: * `createAuthMethodPattern`/`createAuthMethodTypeParamIndex` - a pattern for the method used for create authorization and an optional 0-based index of the parameter passed to that method that denotes the `SObjectType` being authorized for create. * `readAuthMethodPattern`/`readAuthMethodTypeParamIndex` - a pattern for the method used for read authorization and an optional 0-based index of the parameter passed to that method that denotes the `SObjectType` being authorized for read. * `updateAuthMethodPattern`/`updateAuthMethodTypeParamIndex` - a pattern for the method used for update authorization and an optional 0-based index of the parameter passed to that method that denotes the `SObjectType` being authorized for update. * `deleteAuthMethodPattern`/`deleteAuthMethodTypeParamIndex` - a pattern for the method used for delete authorization and an optional 0-based index of the parameter passed to that method that denotes the `SObjectType` being authorized for delete. * `undeleteAuthMethodPattern`/`undeleteAuthMethodTypeParamIndex` - a pattern for the method used for undelete authorization and an optional 0-based index of the parameter passed to that method that denotes the `SObjectType` being authorized for undelete. * `mergeAuthMethodPattern`/`mergeAuthMethodTypeParamIndex` - a pattern for the method used for merge authorization and an optional 0-based index of the parameter passed to that method that denotes the `SObjectType` being authorized for merge. The following example shows how the rule can be configured for the [sirono-common](https://github.com/SCWells72/sirono-common) [`AuthorizationUtil`](https://github.com/SCWells72/sirono-common#authorization-utilities) class: ```xml <rule ref="category/apex/security.xml/ApexCRUDViolation" message="Validate CRUD permission before SOQL/DML operation"> <priority>3</priority> <properties> <property name="createAuthMethodPattern" value="AuthorizationUtil\.(is|assert)(Createable|Upsertable)"/> <property name="readAuthMethodPattern" value="AuthorizationUtil\.(is|assert)Accessible"/> <property name="updateAuthMethodPattern" value="AuthorizationUtil\.(is|assert)(Updateable|Upsertable)"/> <property name="deleteAuthMethodPattern" value="AuthorizationUtil\.(is|assert)Deletable"/> <property name="undeleteAuthMethodPattern" value="AuthorizationUtil\.(is|assert)Undeletable"/> <property name="mergeAuthMethodPattern" value="AuthorizationUtil\.(is|assert)Mergeable"/> </properties> </rule> ``` Note: This rule will produce false positives for VF getter methods. In VF getters the access permission check happens automatically and is not needed explicitly. However, the rule can't reliably determine whether a getter is a VF getter or not and reports a violation in any case. In such cases, the violation should be [suppressed](pmd_userdocs_suppressing_warnings.html). ApexCRUDViolation (Priority

The rule validates you are checking for access permissions before a SOQL/SOSL/DML operation. Since Apex runs by default in system mode not having proper permissions checks results in escalation of privilege and may produce runtime errors. This check forces you to handle such scenarios. Since Winter '23 (API Version 56) you can enforce user mode for database operations by using `WITH USER_MODE` in SOQL. This makes Apex to respect Field-level security (FLS) and object permissions of the running user. When using user mode, no violation is reported by this rule. By default, the rule allows access checks can be performed using system Apex provisions such as `DescribeSObjectResult.isAccessible/Createable/etc.`, the SOQL `WITH SECURITY_ENFORCED` clause, or using the open source [Force.com ESAPI](https://github.com/forcedotcom/force-dot-com-esapi) class library. Because it is common to use authorization facades to assist with this task, the rule also allows configuration of regular expression-based patterns for the methods used to authorize each type of CRUD operation. These pattern are configured via the following properties: * `createAuthMethodPattern`/`createAuthMethodTypeParamIndex` - a pattern for the method used for create authorization and an optional 0-based index of the parameter passed to that method that denotes the `SObjectType` being authorized for create. * `readAuthMethodPattern`/`readAuthMethodTypeParamIndex` - a pattern for the method used for read authorization and an optional 0-based index of the parameter passed to that method that denotes the `SObjectType` being authorized for read. * `updateAuthMethodPattern`/`updateAuthMethodTypeParamIndex` - a pattern for the method used for update authorization and an optional 0-based index of the parameter passed to that method that denotes the `SObjectType` being authorized for update. * `deleteAuthMethodPattern`/`deleteAuthMethodTypeParamIndex` - a pattern for the method used for delete authorization and an optional 0-based index of the parameter passed to that method that denotes the `SObjectType` being authorized for delete. * `undeleteAuthMethodPattern`/`undeleteAuthMethodTypeParamIndex` - a pattern for the method used for undelete authorization and an optional 0-based index of the parameter passed to that method that denotes the `SObjectType` being authorized for undelete. * `mergeAuthMethodPattern`/`mergeAuthMethodTypeParamIndex` - a pattern for the method used for merge authorization and an optional 0-based index of the parameter passed to that method that denotes the `SObjectType` being authorized for merge. The following example shows how the rule can be configured for the [sirono-common](https://github.com/SCWells72/sirono-common) [`AuthorizationUtil`](https://github.com/SCWells72/sirono-common#authorization-utilities) class: ```xml <rule ref="category/apex/security.xml/ApexCRUDViolation" message="Validate CRUD permission before SOQL/DML operation"> <priority>3</priority> <properties> <property name="createAuthMethodPattern" value="AuthorizationUtil\.(is|assert)(Createable|Upsertable)"/> <property name="readAuthMethodPattern" value="AuthorizationUtil\.(is|assert)Accessible"/> <property name="updateAuthMethodPattern" value="AuthorizationUtil\.(is|assert)(Updateable|Upsertable)"/> <property name="deleteAuthMethodPattern" value="AuthorizationUtil\.(is|assert)Deletable"/> <property name="undeleteAuthMethodPattern" value="AuthorizationUtil\.(is|assert)Undeletable"/> <property name="mergeAuthMethodPattern" value="AuthorizationUtil\.(is|assert)Mergeable"/> </properties> </rule> ``` Note: This rule will produce false positives for VF getter methods. In VF getters the access permission check happens automatically and is not needed explicitly. However, the rule can't reliably determine whether a getter is a VF getter or not and reports a violation in any case. In such cases, the violation should be [suppressed](pmd_userdocs_suppressing_warnings.html). ApexCRUDViolation (Priority

The rule validates you are checking for access permissions before a SOQL/SOSL/DML operation. Since Apex runs by default in system mode not having proper permissions checks results in escalation of privilege and may produce runtime errors. This check forces you to handle such scenarios. Since Winter '23 (API Version 56) you can enforce user mode for database operations by using `WITH USER_MODE` in SOQL. This makes Apex to respect Field-level security (FLS) and object permissions of the running user. When using user mode, no violation is reported by this rule. By default, the rule allows access checks can be performed using system Apex provisions such as `DescribeSObjectResult.isAccessible/Createable/etc.`, the SOQL `WITH SECURITY_ENFORCED` clause, or using the open source [Force.com ESAPI](https://github.com/forcedotcom/force-dot-com-esapi) class library. Because it is common to use authorization facades to assist with this task, the rule also allows configuration of regular expression-based patterns for the methods used to authorize each type of CRUD operation. These pattern are configured via the following properties: * `createAuthMethodPattern`/`createAuthMethodTypeParamIndex` - a pattern for the method used for create authorization and an optional 0-based index of the parameter passed to that method that denotes the `SObjectType` being authorized for create. * `readAuthMethodPattern`/`readAuthMethodTypeParamIndex` - a pattern for the method used for read authorization and an optional 0-based index of the parameter passed to that method that denotes the `SObjectType` being authorized for read. * `updateAuthMethodPattern`/`updateAuthMethodTypeParamIndex` - a pattern for the method used for update authorization and an optional 0-based index of the parameter passed to that method that denotes the `SObjectType` being authorized for update. * `deleteAuthMethodPattern`/`deleteAuthMethodTypeParamIndex` - a pattern for the method used for delete authorization and an optional 0-based index of the parameter passed to that method that denotes the `SObjectType` being authorized for delete. * `undeleteAuthMethodPattern`/`undeleteAuthMethodTypeParamIndex` - a pattern for the method used for undelete authorization and an optional 0-based index of the parameter passed to that method that denotes the `SObjectType` being authorized for undelete. * `mergeAuthMethodPattern`/`mergeAuthMethodTypeParamIndex` - a pattern for the method used for merge authorization and an optional 0-based index of the parameter passed to that method that denotes the `SObjectType` being authorized for merge. The following example shows how the rule can be configured for the [sirono-common](https://github.com/SCWells72/sirono-common) [`AuthorizationUtil`](https://github.com/SCWells72/sirono-common#authorization-utilities) class: ```xml <rule ref="category/apex/security.xml/ApexCRUDViolation" message="Validate CRUD permission before SOQL/DML operation"> <priority>3</priority> <properties> <property name="createAuthMethodPattern" value="AuthorizationUtil\.(is|assert)(Createable|Upsertable)"/> <property name="readAuthMethodPattern" value="AuthorizationUtil\.(is|assert)Accessible"/> <property name="updateAuthMethodPattern" value="AuthorizationUtil\.(is|assert)(Updateable|Upsertable)"/> <property name="deleteAuthMethodPattern" value="AuthorizationUtil\.(is|assert)Deletable"/> <property name="undeleteAuthMethodPattern" value="AuthorizationUtil\.(is|assert)Undeletable"/> <property name="mergeAuthMethodPattern" value="AuthorizationUtil\.(is|assert)Mergeable"/> </properties> </rule> ``` Note: This rule will produce false positives for VF getter methods. In VF getters the access permission check happens automatically and is not needed explicitly. However, the rule can't reliably determine whether a getter is a VF getter or not and reports a violation in any case. In such cases, the violation should be [suppressed](pmd_userdocs_suppressing_warnings.html). ApexCRUDViolation (Priority

The rule validates you are checking for access permissions before a SOQL/SOSL/DML operation. Since Apex runs by default in system mode not having proper permissions checks results in escalation of privilege and may produce runtime errors. This check forces you to handle such scenarios. Since Winter '23 (API Version 56) you can enforce user mode for database operations by using `WITH USER_MODE` in SOQL. This makes Apex to respect Field-level security (FLS) and object permissions of the running user. When using user mode, no violation is reported by this rule. By default, the rule allows access checks can be performed using system Apex provisions such as `DescribeSObjectResult.isAccessible/Createable/etc.`, the SOQL `WITH SECURITY_ENFORCED` clause, or using the open source [Force.com ESAPI](https://github.com/forcedotcom/force-dot-com-esapi) class library. Because it is common to use authorization facades to assist with this task, the rule also allows configuration of regular expression-based patterns for the methods used to authorize each type of CRUD operation. These pattern are configured via the following properties: * `createAuthMethodPattern`/`createAuthMethodTypeParamIndex` - a pattern for the method used for create authorization and an optional 0-based index of the parameter passed to that method that denotes the `SObjectType` being authorized for create. * `readAuthMethodPattern`/`readAuthMethodTypeParamIndex` - a pattern for the method used for read authorization and an optional 0-based index of the parameter passed to that method that denotes the `SObjectType` being authorized for read. * `updateAuthMethodPattern`/`updateAuthMethodTypeParamIndex` - a pattern for the method used for update authorization and an optional 0-based index of the parameter passed to that method that denotes the `SObjectType` being authorized for update. * `deleteAuthMethodPattern`/`deleteAuthMethodTypeParamIndex` - a pattern for the method used for delete authorization and an optional 0-based index of the parameter passed to that method that denotes the `SObjectType` being authorized for delete. * `undeleteAuthMethodPattern`/`undeleteAuthMethodTypeParamIndex` - a pattern for the method used for undelete authorization and an optional 0-based index of the parameter passed to that method that denotes the `SObjectType` being authorized for undelete. * `mergeAuthMethodPattern`/`mergeAuthMethodTypeParamIndex` - a pattern for the method used for merge authorization and an optional 0-based index of the parameter passed to that method that denotes the `SObjectType` being authorized for merge. The following example shows how the rule can be configured for the [sirono-common](https://github.com/SCWells72/sirono-common) [`AuthorizationUtil`](https://github.com/SCWells72/sirono-common#authorization-utilities) class: ```xml <rule ref="category/apex/security.xml/ApexCRUDViolation" message="Validate CRUD permission before SOQL/DML operation"> <priority>3</priority> <properties> <property name="createAuthMethodPattern" value="AuthorizationUtil\.(is|assert)(Createable|Upsertable)"/> <property name="readAuthMethodPattern" value="AuthorizationUtil\.(is|assert)Accessible"/> <property name="updateAuthMethodPattern" value="AuthorizationUtil\.(is|assert)(Updateable|Upsertable)"/> <property name="deleteAuthMethodPattern" value="AuthorizationUtil\.(is|assert)Deletable"/> <property name="undeleteAuthMethodPattern" value="AuthorizationUtil\.(is|assert)Undeletable"/> <property name="mergeAuthMethodPattern" value="AuthorizationUtil\.(is|assert)Mergeable"/> </properties> </rule> ``` Note: This rule will produce false positives for VF getter methods. In VF getters the access permission check happens automatically and is not needed explicitly. However, the rule can't reliably determine whether a getter is a VF getter or not and reports a violation in any case. In such cases, the violation should be [suppressed](pmd_userdocs_suppressing_warnings.html). ApexCRUDViolation (Priority