| rule | Description | url | kpi | example |
|---|---|---|---|---|
| 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_ _x000D_ In addition to constructors and initializers, any method called `init` is checked as well._x000D_ _x000D_ Salesforce Apex already protects against this scenario and raises a runtime exception._x000D_ _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. | https://pmd.github.io/latest/pmd_rules_apex_errorprone.html#apexcsrf | Maintainability | |
| 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. | https://pmd.github.io/latest/pmd_rules_apex_security.html#apexbadcrypto | Maintainability | |
| 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_ _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). | https://pmd.github.io/latest/pmd_rules_apex_security.html#apexcrudviolation | Maintainability | |
| ApexDangerousMethods | Checks against calling dangerous methods._x000D_ _x000D_ For the time being, it reports:_x000D_ _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. | https://pmd.github.io/latest/pmd_rules_apex_security.html#apexdangerousmethods | Maintainability | |
| ApexInsecureEndpoint | Checks against accessing endpoints under plain **http**. You should always use_x000D_ **https** for security. | https://pmd.github.io/latest/pmd_rules_apex_security.html#apexinsecureendpoint | Maintainability | |
| ApexOpenRedirect | Checks against redirects to user-controlled locations. This prevents attackers from_x000D_ redirecting users to phishing sites. | https://pmd.github.io/latest/pmd_rules_apex_security.html#apexopenredirect | Maintainability | |
| 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_ _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_ _x000D_ Instead, you should use *Named Credentials* and a callout endpoint._x000D_ _x000D_ For more information, you can check [this](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_callouts_named_credentials.htm) | https://pmd.github.io/latest/pmd_rules_apex_security.html#apexsuggestusingnamedcred | Maintainability | |
| 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. | https://pmd.github.io/latest/pmd_rules_apex_security.html#apexxssfromescapefalse | Maintainability | |
| ApexXSSFromURLParam | Makes sure that all values obtained from URL parameters are properly escaped / sanitized_x000D_ to avoid XSS attacks. | https://pmd.github.io/latest/pmd_rules_apex_security.html#apexxssfromurlparam | Maintainability |