Affects PMD Version: 6.39.0
Rule: ApexCRUDViolation
Please provide the rule name and a link to the rule documentation:
https://pmd.github.io/pmd-6.39.0/pmd_rules_apex_security.html#apexcrudviolation
Description:
This one is going to be similar to the approach proposed (and currently submitted via PR) for #1089. Essentially there are quite a few class libraries that encapsulate pre-CRUD authorization checks, and projects which use those libraries are still flagged for security concerns via this rule. This rule is of course still exceptionally valuable, though, so rather than be an all-or-nothing proposition where the rule is disabled by those using such class libraries, it should be possible to inform the rule about these class libraries so that they can be included in the rule's validation pass. Consider the following example that uses sirono-common's AuthorizationUtil class:
// Use an empty list by default
List<Contact> contacts = new List<Contact>();
// If the user is authorized to read contacts and accounts, query the appropriate contacts and their accounts
if (AuthorizationUtil.isAccessible(Contact.SObjectType) && AuthorizationUtil.isAccessible(Account.SObjectType)) {
contacts = [SELECT Id, Account.Id FROM Contact];
// If the user is authorized to update contacts, update them
if (AuthorizationUtil.isUpdateable(Contact.SObjectType)) {
for (Contact contact : contacts) {
// Do something interesting to each contact
}
update contacts;
} else {
// Report the lack of access
}
} else {
// Report the lack of access
}
Technically that code does perform proper CRUD checks before executing queries and DML statements, but the current rule would flag both the query and the update statement.
Expected outcome:
As with the approach submitted for #1089, it should be possible to register patterns that cause the code above to pass successfully while still flagging issues if AuthorizationUtil (or any other valid) checks are not performed. That would occur via a new rule configuration properties, one per-CRUD operation, additional[Create|Read|Update|Delete|Undelete|Merge]AuthorizationMethodPattern, that are regular expressions for the methods that perform the respective authorization checks, e.g.:
<rule ref="category/apex/security.xml/ApexCRUDViolation" message="...">
<priority>3</priority>
<properties>
<property name="additionalCreateAuthorizationMethodPattern" value="AuthorizationUtil\.(?:is|assert)(?:Createable|Upsertable)\((\w+)\.SObjectType\)" />
<property name="additionalReadAuthorizationMethodPattern" value="AuthorizationUtil\.(?:is|assert)Accessible\((\w+)\.SObjectType\)" />
<property name="additionalUpdateAuthorizationMethodPattern" value="AuthorizationUtil\.(?:is|assert)(?:Updateable|Upsertable)\((\w+)\.SObjectType\)" />
<property name="additionalDeleteAuthorizationMethodPattern" value="AuthorizationUtil\.(?:is|assert)Deletable\((\w+)\.SObjectType\)" />
<property name="additionalUndeleteAuthorizationMethodPattern" value="AuthorizationUtil\.(?:is|assert)Undeletable\((\w+)\.SObjectType\)" />
<property name="additionalMergeAuthorizationMethodPattern" value="AuthorizationUtil\.(?:is|assert)Mergeable\((\w+)\.SObjectType\)" />
</properties>
</rule>
Note the capture group in each pattern that is included to capture the specific SObjectType being authorized. This will be important to ensure that the correct SObjectTypes are properly authorized before the respective CRUD activity.
I'll take a stab at this approach and, assuming it bears fruit, I'll open a pull request shortly.
Running PMD through: [CLI | Ant | Maven | Gradle | Designer | Other]
CLI and direct API-based integration
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4