This version switches to SonarQube 6.0 API. This version no longer supports any earlier versions than version 6.0 of SonarQube.
Avoid untrusted/unescaped variables in DML query
Detects the usage of untrusted / unescaped variables in DML queries. This detect SOQL Injection type attacks
Avoid making DML operations in constructor/initialisation method
Check to avoid making DML operations in Apex class constructor/init method. This prevents
modification of the database just by accessing a page. This avoids CSRF type attacks
Unescaped error message XSS
Reports on calls to addError with disabled escaping. The message passed to addError
will be displayed directly to the user in the UI, making it prime ground for XSS
attacks if unescaped.
URL parameters should be escaped/sanitized
Makes sure that all values obtained from URL parameters are properly escaped / sanitized to avoid XSS attacks.
Avoid using hard coded credentials for authentication
Detects hardcoded credentials used in requests to an endpoint.
Sharing should be configured on classes that make use of DML
Executing DML should be done inside a class annotated with ‘with sharing’ or ‘without sharing’.
By setting allowWithoutSharing=false, DML in classes flagged with ‘without sharing’ are still flagged.
This can be useful for manual reviews of classes working around security problems.
Avoid Cleartext Transmission of Sensitive Information
Checks against accessing endpoints under plain http. You should always use https for security.
Apex classes should use random IV/key
The rule makes sure you are using randomly generated IVs and keys for Crypto calls.
Hard-wiring these values greatly compromises the security of encrypted data.
URL Redirection to Untrusted Site
Checks against redirects to user-controlled locations.
Unencoded formulas in script tags XSS
Makes sure that all values obtained from URL parameters are properly escaped / sanitized to avoid XSS attacks.
Unescaped output text XSS
Reflected Cross-site Scripting (XSS) occur when an attacker injects browser executable code within a single HTTP response.
Reflected Javascript XSS
Reflected Cross-site Scripting (XSS) occur when an attacker injects browser executable code within a single HTTP response.
Unescaped attribute value XSS
Reflected Cross-site Scripting (XSS) occur when an attacker injects browser executable code within a single HTTP response.
Avoid declaring non-final public static fields
There is no good reason to declare a field “public” and “static” without also declaring it “final”. Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.
Classes should not have global accessibility
Global classes should be avoided (especially in managed packages) as they can never be deleted or changed in signature. Always check twice if something needs to be global. Many interfaces (e.g. Batch, Schedulable, WebServiceMock, HttpCalloutMock) required global modifiers in the past but don’t require this anymore. Don’t lock yourself in.
Avoid Logic in Triggers
As triggers do not allow methods like regular classes they are less flexible and suited to apply good encapsulation style. Therefore delegate the triggers work to a regular class (often called Trigger handler class).
The exception to this rule is you may check the Trigger.is* context (Trigger.isInsert for example) inside an if statement.
Read more here: https://developer.salesforce.com/page/Trigger_Frameworks_and_Apex_Trigger_Best_Practices
Class variable fields should not have public accessibility
Public class variables have some disadvantages:
Avoid calling Super twice in a Constructor
Calling super in a constructor multiple times can be confusing. Try to use a single constructor.
Comment is required
Denotes whether comments are required (or unwanted) for specific language elements.
One variable declaration per line
Apex allows the use of several variable declarations of the same type on one line. However, it
can lead to quite messy code. This rule looks for several declarations on the same line.
Avoid prefixing method parameters
Prefixing parameters by ‘in’ or ‘out’ pollutes the name of the parameters and reduces code readability.
To indicate whether or not a parameter will be modified in a method, its better to document method
behavior with comments.
Avoid using hard-coded literals in conditional statements
By declaring them as static variables or private members with descriptive names maintainability is enhanced.
By default, the literals “-1” and “0” are ignored.
More exceptions can be defined with the property “ignoreMagicNumbers”.
Short class names
Classes with short names are not recommended.
Exception as flow control
Using Exceptions as form of flow control is not recommended as they obscure true exceptions when debugging.
Either add the necessary validation or use an alternate control structure.
Always comment empty constructors
Finds instances where a constructor does not contain statements, but there is no comment.
By explicitly commenting empty constructors it is easier to distinguish between intentional
(commented) and unintentional empty constructors.
Always comment empty methods
Finds instances where a method does not contains statements, but there is no comment.
By explicitly commenting empty methods it is easier to distinguish between intentional (commented) and
unintentional empty methods.
trigger (…){
integer test2 { get; set; }
}