SonarJS 6.4.1

Bugfix release:

• Filtering out huge files is now applied only to JS/TS.

SonarJS 6.4

New rules:

• S2598: File uploads should be restricted (formidable)
• S4502: Disabling CSRF protection is security-sensitive
• S4507: Delivering code in production with debug features activated is security-sensitive
• S5689: Recovering fingerprints from web application technologies should not be possible
• S5691: Statically serving hidden files is security-sensitive
• S5693: Allowing requests with excessive content length is security-sensitive

Improved rules:

• S5122: now raised only when permissive CORS policy is obvious; Support for cors middleware.

Deprecated rules:

• S1442 (superseded by S4507)
• S1525 (superseded by S4507)

Changes in the requirements:

• The plugin now requires Node.js 10
• The plugin no longer relies on user-provided TypeScript: TypeScript is now shipped with the analyzer.
• Support for solution-style tsconfigs
• Very large files are now excluded from analysis by default (property sonar.javascript.maxFileSize controls the threshold)

6.3.0.12464

Hardening and bugfixes

Analyzer for JavaScript/TypeScript 6.2.1

Fix bug in SonarLint when analyzing JS file before TS file (#1680)

SonarJS 6.2

Hi,

This release adds 31 rules for TypeScript which were available for JavaScript:

• Rule S1119: Labels should not be used
• Rule S128: Switch cases should end with an unconditional "break" statement
• Rule S1529: Bitwise operators should not be used in boolean contexts
• Rule S134: Control flow statements "if", "for", "while", "switch" and "try" should not be nested too deeply
• Rule S3973: A conditionally executed single line should be denoted by indentation
• Rule S2392: Variables should be used in the blocks where they are declared
• Rule S3524: Braces and parentheses should be used consistently with arrow functions
• Rule S3317: Default export names and file names should match
• Rule S3499: Shorthand object properties should be grouped at the beginning or end of an object declaration
• Rule S3514: Destructuring syntax should be used for assignments
• Rule S3513: "arguments" should not be accessed directly
• Rule S2310: Loop counters should not be assigned to from within the loop body
• Rule S2692: "indexOf" checks should not be for positive numbers
• Rule S1994: "for" loop increment clauses should modify the loops' counters
• Rule S2137: Special identifiers should not be bound or assigned
• Rule S1515: Functions should not be defined inside loops
• Rule S2427: The base should be provided to "parseInt"
• Rule S2208: Wildcard imports should not be used
• Rule S888: Equality operators should not be used in "for" loop termination conditions
• Rule S1530: Function declarations should not be made within blocks
• Rule S1848: Objects should not be created to be dropped immediately without being used
• Rule S1539: "strict" mode should be used with caution
• Rule S1128: Unnecessary imports should be removed
• Rule S1472: Function call arguments should not start on new lines
• Rule S1219: "switch" statements should not contain non-case labels
• Rule S100: Function and method names should comply with a naming convention
• Rule S124: Track comments matching a regular expression
• Rule S1134: Track uses of "FIXME" tags
• Rule S1067: Expressions should not be too complex
• Rule S1135: Track uses of "TODO" tags
• Rule S126: "if ... else if" constructs should end with "else" clauses

Finally, this version may also significantly reduce the analysis time for big projects.

We hope you will like this new version.

SonarJS 6.1

Hi,

With this release, the analyzer now provides analysis for both JavaScript and TypeScript code.

In addition to the rules previously provided by the TypeScript analyzer, TypeScript now benefits from all 12 Security Hotspot rules which existed for JavaScript:

• Rule S2255: Writing cookies is security-sensitive.
• Rule S5122: Enabling Cross-Origin Resource Sharing is security-sensitive.
• Rule S4787: Encrypting data is security-sensitive.
• Rule S4790: Hashing data is security-sensitive.
• Rule S4721: Executing OS commands is security-sensitive.
• Rule S4823: Using command line arguments is security-sensitive.
• Rule S2245: Using pseudorandom number generators (PRNGs) is security-sensitive.
• Rule S4784: Using regular expressions is security-sensitive.
• Rule S4818: Using Sockets is security-sensitive.
• Rule S2077: Formatting SQL queries is security-sensitive.
• Rule S4829: Reading the Standard Input is security-sensitive.
• Rule S4817: Executing XPath expressions is security-sensitive.

JavaScript has also new Bug, Code Smell and Security HotSpot rules which were available for TypeScript:

• Rule S4275: Getters and setters should access the expected fields (Bug)
• Rule S4326: “await” should not be used redundantly (Code Smell)
• Rule S109: Magic numbers should not be used (Code Smell)
• Rule S4140: Sparse arrays should not be declared (Code Smell)
• Rule S3696: Literals should not be thrown (Code Smell)
• Rule S4624: Template literals should not be nested (Code Smell)
• Rule S117: Variable, property and parameter names should comply with a naming convention (Code Smell)
• Rule S1821: "switch" statements should not be nested (Code Smell)
• Rule S2068: Hard-coded credentials are security-sensitive (Security HotSpot)

TypeScript 3.2.1 or higher is required for TypeScript analysis. Note that this version of TypeScript is necessary only during the analysis. You can still use a different version to run your software.
You also need to upgrade the TypeScript analyzer to v2.1 in order to avoid conflicts.

Finally, make sure that you have NodeJS installed before running the analyzer.

We hope you will like this new version.

SonarJS 5.2.1

Hi,

This version fixes a bug introduced in version 5.2: #1264 LCOV parser cannot resolve absolute paths

SonarJS 5.2

Hi,

This release adjusts Security Hotspot rules to better help developers review their code and find vulnerabilities. Security Hotspot rules were at first designed for security audits. We now believe that they provide even more value during normal code reviews, i.e. to developers. This however required some changes.

We updated three rules:
Rule S4784 "Using regular expressions is security-sensitive"
It will only raise issues on hard-coded regular expressions which have at least 3 characters and at least two instances of any of the following characters: *+{. This will avoid raising issues on regular expressions which are too simple to be dangerous.
The rule will not raise anymore on dynamic regular expressions, i.e. regular expressions for which we have no information (ex: passed as parameters). This was useful for a security auditor but not for a developer as it would raise in too many places, making code review more complex than necessary. However keep in mind that this is still a possible attack vector.

Rule S2077 "Formatting SQL queries is security-sensitive"
It will only raise when it detects that an SQL query is created via concatenation. This is often a bad practice which can result in an SQL injection. Even when no injection is possible it is better to use bound arguments as it makes code review easier.
Same as for rule S4784, the rule will not raise anymore on dynamic SQL queries, i.e. sql queries for which we have no information (ex: passed as parameter).

Rule S2255 "Writing cookies is security-sensitive"
It will only raise when cookies are written, not when cookies are read. This makes the rule focused on sensitive information exposure alone, instead of covering both exposure and injection risks.

Three more rules have been removed because they provided value to security auditors only and would make code review more complex for developers:

• S4797 Handling files is security-sensitive
• S4825 Sending HTTP requests is security-sensitive
• S4529 Exposing HTTP endpoints is security-sensitive

We hope you will enjoy this new version of SonarJS and welcome any feedback.

SonarJS 5.1

Hi,

This release focuses on Security Hotspot rules, which identify security-sensitive areas of code. They help Security Analysts determine if a vulnerability is present in a software by guiding them during code reviews.

This new set of Security Hotspot rules find some of the most common security-sensitive code patterns, such as executing regular expression or encrypting data.

Each rule explains the danger which might be lurking, lists questions which should be answered to find out if the code is vulnerable or not, and provides recommendations. They are enabled by default and should be reviewed in SonarQube's Security Reports space.

SonarJS 5.1 brings 15 new Security Hotspot rules:

• Rule S5122: Enabling Cross-Origin Resource Sharing is security-sensitive
• Rule S4825: Sending HTTP requests is security-sensitive
• Rule S4784: Using regular expressions is security-sensitive
• Rule S4817: Executing XPath expressions is security-sensitive
• Rule S2077: Executing SQL queries is security-sensitive
• Rule S4790: Hashing data is security-sensitive
• Rule S4818: Using Sockets is security-sensitive
• Rule S4529: Exposing HTTP endpoints is security-sensitive
• Rule S4797: Handling files is security-sensitive
• Rule S4787: Encrypting data is security-sensitive
• Rule S2255: Using cookies is security-sensitive
• Rule S4823: Using command line arguments is security-sensitive
• Rule S4829: Reading the Standard Input is security-sensitive
• Rule S4721: Executing OS commands is security-sensitive
• Rule S2245: Using pseudorandom number generators (PRNGs) is security-sensitive

SonarJS 5.0

Hey,

This version brings 5 new rules:

• Rule S1940: Boolean checks should not be inverted new-rule #973
• Rule S2737: "catch" clauses should do more than rethrow common-rule new-rule #951
• Rule S1479: "switch" statements should not have too many "case" clauses common-rule new-rule #945
• Rule S1192: String literals should not be duplicated common-rule new-rule #943
• Rule S2428: Object literal syntax should be used new-rule #699

Note that starting from this version SonarJS requires Node.js to be available during execution.