Release notes

This version switches to SonarQube™ 6.0 API. This version no longer supports any earlier versions than version 6.0 of SonarQube™.

Improvements:

Support for CodeScan for Eclipse version 2.5
Support for CodeScan for SonarQube™ 6.3
Code coverage now reports at a per-line granuality
Upgraded force.com APIs
ASTTriggerDeclaration.on and ASTTriggerDeclaration.isBulk is now accessible for XPath
Support for NTLM Proxies
Lots of rule documentation improvements
A ‘statement’ and ‘public undocumented api’ metrics is now recorded
VisualForce Macro parsing errors are now reported against a Tracking Violation
CodeScan proxy can now be configured from SonarQube™. Note that configuration for the download Salesforce code step cannot use this configuration, so the http.proxyHost method is still recommended.
CodeScan bundler now supports proxies

New Apex Security rules:

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.

New VisualForce rules:

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.

New Apex rules:

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.

Class variable fields should not have public accessibility
Public class variables have some disadvantages:

The internal representation is exposed, and thus cannot be easily changed
When the value is changed in an unexpected way (for example nulled), the implementation may not handle it correctly
Additional validation logic cannot be added

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.

Parsing fixes:

Allow interface declaration in triggers.

Supports trigger accessors better

trigger (…){
integer test2 { get; set; }
}

Supports for global and interfaces in triggers

Changes

Sync unit testing has been removed (async should always work better)
Unit test disabled is deprecated (use disabled unit test mode)
Several Rules were deprecated that never should have been added

Bug Fixes:

Fixed a versioning issue in force-versions download
Fixed several async/history unit tests bugs (3.6-RC11)
Fixed a bug in the symbol table resolution
Fixed some bugs in force-versions API for downloading and commits to git
Fixed a bug in history building when the related class for a result is deleted (3.6.2)
Fixed a bug when running SonarQube™ on windows (3.6-RC14)
Fixed a false-positive on NonUnitTestContainsAsserts
Referenced Packages no longer fail to parse i.e. (hidden) files
Fixed ConstructorCallsOverridableMethod exception on Triggers
Fixed UnusedPrivateMethod false postive on @setupMethod functions
DMLWithoutSharingEnabled doesn’t flag DML when in ‘Without Sharing’ is set (unless configured otherwise)
DU analysis hangs in some scenarios (3.7.6)
Recursion bug in SOQLInjection (3.7.8)

{[{category.name}]}