diff --git a/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S121.html b/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S121.html index 7749314fe6..1b213d7103 100644 --- a/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S121.html +++ b/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S121.html @@ -12,9 +12,7 @@
Credentials should be stored outside of the code in a configuration file, a database or secret management service.
+Credentials should be stored outside of the code in a configuration file, a database, or a management service for secrets.
This rule flags instances of hard-coded credentials used in database and LDAP connections. It looks for hard-coded credentials in connection strings, and for variable names that match any of the patterns from the provided list.
It's recommended to customize the configuration of this rule with additional credential words such as "oauthToken", "secret", ...
@@ -20,7 +20,7 @@This rule raises an issue when the whitespacing of the lines after a one line block indicates an intent to include those lines in the block, but the omission of curly braces means the lines will be unconditionally executed once.
+Note that this rule considers tab characters to be equivalent to 1 space. If you mix spaces and tabs you will sometimes see issues in code which +looks fine in your editor but is confusing when you change the size of tabs.
if (condition) diff --git a/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S2819.html b/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S2819.html index c05eec4b7d..9404ab325b 100644 --- a/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S2819.html +++ b/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S2819.html @@ -1,9 +1,11 @@Browsers allow message exchanges between Window objects of different origins.
Because any window can send / receive messages from other window it is important to verify the sender's / receiver's identity:
-- When sending message with postMessage method, the identity's receiver should be defined (the wildcard keyword (
-*
) should not be -used).- When receiving message with message event, the sender's identity should be verified using the origin and possibly source properties.
+
*
) should not be
+ used). When sending message:
diff --git a/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S4507.html b/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S4507.html index 3342406a80..b276263ac6 100644 --- a/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S4507.html +++ b/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S4507.html @@ -15,22 +15,6 @@Ask Yourself Whether
Recommended Secure Coding Practices
Do not enable debug features on production servers.
Sensitive Code Example
-The debugger statement should be removed in -production:
--for (i = 1; i<5; i++) { - // Print i to the Output window. - Debug.write("loop index is " + i); - // Wait for user to resume. - debugger; // Sensitive -} ---
alert()
,confirm()
andprompt()
instructions should be removed in production:-if(unexpectedCondition) { - alert("Unexpected Condition"); // Sensitive -} -errorhandler Express.js middleware should not be used in production:
const express = require('express'); diff --git a/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S4822.html b/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S4822.html index 69c292ccc2..4e94867e60 100644 --- a/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S4822.html +++ b/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S4822.html @@ -1,7 +1,7 @@An exception (including
-reject
) thrown by a promise will not be caught by a nestingtry
block, due to the asynchronous nature of execution. Instead, usecatch
method ofPromise
or wrap it insideawait
expression.This rule reports
+try-catch
statements containing nothing else but call(s) to a function returning aPromise
(thus -it's less likely thatcatch
is intended to catch something else thanPromise
rejection).This rule reports
try-catch
statements containing nothing else but call(s) to a function returning aPromise
(thus it's +less likely thatcatch
is intended to catch something else thanPromise
rejection).Noncompliant Code Example
function runPromise() { diff --git a/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S5247.html b/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S5247.html index cd38640593..3639bf64d9 100644 --- a/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S5247.html +++ b/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S5247.html @@ -2,7 +2,7 @@Groovy's template engine
, allow configuration of automatic variable escaping before rendering templates. When escape occurs, characters that make sense to the browser (eg: <a>) will be transformed/replaced with escaped/sanitized values (eg: & lt;a& gt; ).Auto-escaping is not a magic feature to annihilate all cross-site scripting attacks, it depends on the strategy applied and the context, for example a "_html auto-escaping_" strategy +href="https://twig.symfony.com/doc/3.x/filters/escape.html">the strategy applied and the context, for example a "html auto-escaping" strategy (which only transforms html characters into html entities) will not be relevant when variables are used in a html attribute because '
@@ -20,10 +20,8 @@:
' character is not escaped and thus an attack as below is possible:Ask Yourself Whether
There is a risk if you answered yes to any of those questions.
Recommended Secure Coding Practices
-
Enable auto-escaping by default and continue to review the use of inputs in order to be sure that the chosen auto-escaping strategy is the right +one.
mustache.js template engine:
@@ -130,4 +128,4 @@* Some powerful features used by the application are not really necessary.
-* Users are not clearly informed why and when powerful features are used by the application.
+You are at risk if you answered yes to any of those questions.
* In order to respect user privacy it is recommended to avoid using intrusive powerful features.
+When using geolocation API, Firefox for example retrieves personal
information like nearby wireless access points and IP address and sends it to the default geolocation service provider, Compliant Solution
</html>
* OWASP Web Top 10 2017 Category A3 - Sensitive Data
-Exposure * CWE-250 - Execution with Unnecessary Privileges * CWE-359 - Exposure of Private Information * W3C - Permissions * Mozilla - Does Firefox share my location with
-websites? jsonwebtoken library: * OWASP Testing Guide - OTG-INFO-008 -
-Fingerprint Web Application Framework * OWASP Testing Guide - OTG-INFO-009 - Fingerprint Web
-Application * OWASP Top 10 2017 Category A6 - Security
-Misconfiguration * MITRE, CWE-200 - Information Exposure Outside of the user environment, hidden files are sensitive because they are used to store privacy-related information or even hard-coded
secrets. * Hidden files may have been inadvertently uploaded to the static server's public directory and it accepts requests to hidden files. * There is no business use cases linked to serve files in There is a risk if you answered yes to any of those questions. * Disable the serving of hidden files. Express.js serve-static middleware: * CWE-538 - File and Directory Information Exposure There is a risk if you answered yes to any of those questions. lower or equal to 8mb for file uploads. lower or equal to 2mb for other requests. It is recommended to customize the rule with the limit values that correspond to the web application. formidable file upload module: There is a risk if you answered yes to this question. Implement content security policy fetch directives, in particular default-src directive and continue to properly sanitize and validate all
+inputs of the application, indeed CSP fetch directives is only a tool to reduce the impact of cross site scripting attacks. In a Express.js application, the code is sensitive if the helmet contentSecurityPolicy
middleware is disabled: There is a risk if you answered yes to this question. Implement content security policy block-all-mixed-content directive which is supported by all modern browsers and will block loading of
+mixed-contents. In Express.js application the code is sensitive if the helmet-csp or helmet middleware is used without the Clickjacking attacks occur when an attacker try to trick an user to click on certain
buttons/links of a legit website. This attack can take place with malicious HTML frames well hidden in an attacker website. For instance, suppose a safe and authentic page of a social network (https://socialnetworkexample.com/make_myprofil_public) which allows an user to
+ For instance, suppose a safe and authentic page of a social network (https://socialnetworkexample.com/makemyprofilpublic) which allows an user to
change the visibility of his profile by clicking on a button. This is a critical feature with high privacy concerns. Users are generally well informed
on the social network of the consequences of this action. An attacker can trick users, without their consent, to do this action with the below
embedded code added on a malicious website: Playing with the size of the iframe it's sometimes possible to display only the critical parts of a page, in this case the button of the
-makemyprofil_public_ page.See
-
+
diff --git a/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S5659.html b/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S5659.html
index ece29d0cc2..edd3d9c0a2 100644
--- a/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S5659.html
+++ b/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S5659.html
@@ -9,9 +9,9 @@ Noncompliant Code Example
const jwt = require('jsonwebtoken');
-let token = jwt.sign({ foo: 'bar' }, key, { algorithm: 'none' }); // Noncompliant: JWT should include a signature
+let token = jwt.sign({ foo: 'bar' }, key, { algorithm: 'none' }); // Noncompliant: 'none' cipher doesn't sign the JWT (no signature will be included)
-jwt.verify(token, key, { expiresIn: 360000 * 5, algorithms: ['RS256', 'none'] }, callbackcheck); // Noncompliant: none algorithm should not be used when verifying JWT signature
+jwt.verify(token, key, { expiresIn: 360000 * 5, algorithms: ['RS256', 'none'] }, callbackcheck); // Noncompliant: 'none' cipher should not be used when verifying JWT signature
Compliant Solution
See
Compliant Solution
app2.use(helmet.hidePoweredBy());
See
-
+
diff --git a/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S5691.html b/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S5691.html
index 44dc5be195..57df1f31fc 100644
--- a/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S5691.html
+++ b/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S5691.html
@@ -4,12 +4,16 @@
Ask Yourself Whether
-.name
format but the server is not configured to reject requests to this
-type of files.
+
.name
format but the server is not configured to reject requests to this
+ type of files. Recommended Secure Coding Practices
-
+
Sensitive Code Example
@@ -33,6 +37,7 @@
See
Ask Yourself Whether
Recommended Secure Coding Practices
-
-
+
Sensitive Code Example
Ask Yourself Whether
Recommended Secure Coding Practices
-
-
+Sensitive Code Example
Ask Yourself Whether
Recommended Secure Coding Practices
-
-
+Sensitive Code Example
blockAllMixedContent
directive:
There is a risk if you answered yes to this question.
Implement content security policy frame-ancestors directive which is supported by all modern browsers and will specify the origins of +frame allowed to be loaded by the browser (this directive deprecates X-Frame-Options).
In Express.js application the code is sensitive if the helmet-csp or helmet middleware is used without the frameAncestors
directive (or if
diff --git a/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S5734.html b/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S5734.html
index 3bc7d4d8d4..f5dbbc8524 100644
--- a/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S5734.html
+++ b/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S5734.html
@@ -5,7 +5,7 @@
server, but often this header is not set or is set with an incorrect value. To avoid content-type mismatch and to provide the best user experience,
web browsers try to deduce the right content-type, generally by inspecting the content of the resources (the first bytes). This "guess mechanism" is
called MIME type sniffing.
Attackers can take advantage of this feature when a website (_example.com_ here) allows to upload arbitrary files. In that case, an attacker can +
Attackers can take advantage of this feature when a website ("example.com" here) allows to upload arbitrary files. In that case, an attacker can upload a malicious image fakeimage.png (containing malicious JavaScript code or a polyglot content file) such as:
@@ -21,12 +21,10 @@Ask Yourself Whether
There is a risk if you answered yes to any of those questions.
Recommended Secure Coding Practices
-
Implement X-Content-Type-Options header with +nosniff value (the only existing value for this header) which is supported by all modern browsers and will prevent browsers from performing +MIME type sniffing, so that in case of Content-Type header mismatch, the resource is not interpreted. For example within a <script> object +context, JavaScript MIME types are expected (like application/javascript) in the Content-Type header.
In Express.js application the code is sensitive if, when using helmet, the noSniff
middleware is disabled:
HTTP header referer contains a URL set by web browsers and used by applications to track from where the user came from, it's for instance a relevant value for web analytic services, but it can cause serious privacy and security problems -if the URL contains confidential information. Note that Firefox for instance to prevent data leaks removes path information in the Referer header while browsing privately.
Suppose an e-commerce website asks the user his credit card number to purchase a product:
@@ -15,15 +15,15 @@ </form> </body> -When submitting the above HTML form a HTTP GET request will be performed, the URL requested will be +
When submitting the above HTML form, a HTTP GET request will be performed, the URL requested will be https://example.com/valid_order?cc=1111-2222-3333-4444 with credit card number inside and it's obviously not secure for these reasons:
In addition to these threats, when further requests will be performed from the validorder_ page with a simple legitimate embedded script -like that:
+In addition to these threats, when further requests will be performed from the "valid_order" page with a simple legitimate embedded script like +that:
<script src="https://webanalyticservices_example.com/track">@@ -40,11 +40,9 @@
There is a risk if you answered yes to any of those questions.
unsafe-url
or no-referrer-when-downgrade
, allows to control how much information is included in the referer header. Confidential information should not be set inside URLs (GET requests) of the application and a safe (ie: different from unsafe-url
or
+no-referrer-when-downgrade
) referrer-Policy
+header, to control how much information is included in the referer header, should be used.
In Express.js application the code is sensitive if the helmet referrerPolicy
middleware is disabled or used with no-referrer-when-downgrade
or unsafe-url
:
There is a risk if you answered yes to this question.
Implement Strict-Transport-Security policy header, it is recommended to apply this policy to all subdomains (includeSubDomains
) and
+for at least 6 months (max-age=15552000
) or even better for 1 year (max-age=31536000
).
In Express.js application the code is sensitive if the helmet or hsts middleware are disabled or used without recommended values:
diff --git a/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S5742.html b/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S5742.html index 7bf448f76a..fa420bfc18 100644 --- a/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S5742.html +++ b/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S5742.html @@ -10,11 +10,9 @@There is a risk if you answered yes to this question.
Implement Expect-CT HTTP header which instructs the web browser +to check public CT logs in order to verify if the website appears inside and if it +is not, the browser will block the request and display a warning to the user.
In Express.js application the code is sensitive if the expect-ct middleware is disabled:
diff --git a/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S5743.html b/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S5743.html index 048ee3eb85..e4ca632593 100644 --- a/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S5743.html +++ b/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S5743.html @@ -15,10 +15,8 @@Ask Yourself Whether
There is a risk if you answered yes to this question.
Recommended Secure Coding Practices
-
Implement X-DNS-Prefetch-Control header with an +off value but this could significantly degrade website performances.
In Express.js application the code is sensitive if the dns-prefetch-control middleware is disabled or used without the recommended value:
@@ -57,4 +55,4 @@There is a risk if you answered yes to any of those questions.
Loggers should be configured with a list of confidential, personal information that will be hidden/masked or removed from logs.
With Signale log management framework the code is sensitive when an empty list of secrets is defined:
@@ -59,4 +57,4 @@There is a risk if you answered yes to this question.
User IP address should not be forwarded unless the application needs it, as part of an authentication, authorization scheme or log management for +examples.
diff --git a/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/Sonar_way_profile.json b/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/Sonar_way_profile.json index 32b3275a3e..4e196db6f3 100644 --- a/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/Sonar_way_profile.json +++ b/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/Sonar_way_profile.json @@ -127,9 +127,10 @@ "S5732", "S5734", "S5736", + "S5739", "S5742", "S5743", "S5757", "S5759" ] -} +} diff --git a/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/Sonar_way_recommended_profile.json b/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/Sonar_way_recommended_profile.json index 66ae8fe14d..f6a04fc619 100644 --- a/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/Sonar_way_recommended_profile.json +++ b/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/Sonar_way_recommended_profile.json @@ -198,8 +198,9 @@ "S5732", "S5734", "S5736", + "S5739", "S5742", "S5743", "S5757" ] -} +} diff --git a/sonarpedia.json b/sonarpedia.json index 68eb3336d2..4eba695186 100644 --- a/sonarpedia.json +++ b/sonarpedia.json @@ -3,7 +3,7 @@ "languages": [ "JS" ], - "latest-update": "2020-10-22T12:28:35.587858700Z", + "latest-update": "2020-11-12T12:21:21.957503300Z", "options": { "no-language-in-filenames": true, "preserve-filenames": true