ApexCSRFHaving 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.
ApexBadCryptoThe 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.
ApexCRUDViolationThe 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).
ApexDangerousMethodsChecks 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.
ApexInsecureEndpointChecks against accessing endpoints under plain **http**. You should always use_x000D_
**https** for security.
ApexOpenRedirectChecks against redirects to user-controlled locations. This prevents attackers from_x000D_
redirecting users to phishing sites.
ApexSOQLInjectionDetects the usage of untrusted / unescaped variables in DML queries.
ApexSuggestUsingNamedCredDetects 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_
and error-prone._x000D_
Instead, you should use *Named Credentials* and a callout endpoint._x000D_
For more information, you can check [this](
ApexXSSFromEscapeFalseReports 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.
ApexXSSFromURLParamMakes sure that all values obtained from URL parameters are properly escaped / sanitized_x000D_
to avoid XSS attacks.