|ApexCSRF||Having DML operations in Apex class constructor or initializers can have unexpected side effects:_x000D_|
By just accessing a page, the DML statements would be executed and the database would be modified._x000D_
Just querying the database is permitted._x000D_
In addition to constructors and initializers, any method called `init` is checked as well._x000D_
Salesforce Apex already protects against this scenario and raises a runtime exception._x000D_
Note: This rule has been moved from category "Security" to "Error Prone" with PMD 6.21.0, since_x000D_
using DML in constructors is not a security problem, but crashes the application.
|ApexBadCrypto||The rule makes sure you are using randomly generated IVs and keys for `Crypto` calls._x000D_|
Hard-wiring these values greatly compromises the security of encrypted data.
|ApexCRUDViolation||The rule validates you are checking for access permissions before a SOQL/SOSL/DML operation._x000D_|
Since Apex runs in system mode not having proper permissions checks results in escalation of_x000D_
privilege and may produce runtime errors. This check forces you to handle such scenarios._x000D_
Note: This rule will produce false positives for VF getter methods. In VF getters the access permission_x000D_
check happens automatically and is not needed explicitly. However, the rule can't reliably determine_x000D_
whether a getter is a VF getter or not and reports a violation in any case. In such cases, the violation_x000D_
should be [suppressed](pmd_userdocs_suppressing_warnings.html).
|ApexDangerousMethods||Checks against calling dangerous methods._x000D_|
For the time being, it reports:_x000D_
* Against `FinancialForce`'s `Configuration.disableTriggerCRUDSecurity()`. Disabling CRUD security_x000D_
opens the door to several attacks and requires manual validation, which is unreliable._x000D_
* Calling `System.debug` passing sensitive data as parameter, which could lead to exposure_x000D_
of private data.
|ApexInsecureEndpoint||Checks against accessing endpoints under plain **http**. You should always use_x000D_|
**https** for security.
|ApexOpenRedirect||Checks against redirects to user-controlled locations. This prevents attackers from_x000D_|
redirecting users to phishing sites.
|ApexSOQLInjection||Detects the usage of untrusted / unescaped variables in DML queries.||https://pmd.github.io/latest/pmd_rules_apex_security.html#apexsoqlinjection||Maintainability|
|ApexSuggestUsingNamedCred||Detects hardcoded credentials used in requests to an endpoint._x000D_|
You should refrain from hardcoding credentials:_x000D_
* They are hard to mantain by being mixed in application code_x000D_
* Particularly hard to update them when used from different classes_x000D_
* Granting a developer access to the codebase means granting knowledge_x000D_
of credentials, keeping a two-level access is not possible._x000D_
* Using different credentials for different environments is troublesome_x000D_
Instead, you should use *Named Credentials* and a callout endpoint._x000D_
For more information, you can check [this](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_callouts_named_credentials.htm)
|ApexXSSFromEscapeFalse||Reports on calls to `addError` with disabled escaping. The message passed to `addError`_x000D_|
will be displayed directly to the user in the UI, making it prime ground for XSS_x000D_
attacks if unescaped.
|ApexXSSFromURLParam||Makes sure that all values obtained from URL parameters are properly escaped / sanitized_x000D_|
to avoid XSS attacks.