Update rule metadata (#4480)

css-sonarpedia/sonarpedia.json

@@ -3,7 +3,7 @@
   "languages": [
     "CSS"
   ],
-  "latest-update": "2023-11-01T10:11:33.309415200Z",
+  "latest-update": "2023-12-21T17:13:56.851986Z",
   "options": {
     "no-language-in-filenames": true
   }

sonar-plugin/css/src/main/resources/org/sonar/l10n/css/rules/css/S4663.html

@@ -1,11 +1,11 @@
 <h2>Why is this an issue?</h2>
-<p>Empty comments like the following don’t improve readability and might indicate an oversight.</p>
+<p>Empty comments, as shown in the example, hurt readability and might indicate an oversight.</p>
 <pre>
 /*  */
 
 /*
 
  */
 </pre>
-<p>A meaningful text should be added to the comment or the comment markers should be removed.</p>
+<p>Some meaningful text should be added to the comment, or the comment markers should be removed.</p>
 

sonar-plugin/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S2187.html

@@ -6,10 +6,10 @@ <h2>Why is this an issue?</h2>
   <li> An incomplete test suite: Perhaps the developer started writing tests but didn’t finish. </li>
   <li> A mistake: The developer might have accidentally deleted the test cases or moved them to another file. </li>
 </ul>
-<p>This rule flags any file that has a <code>.test</code> or <code>.spec</code> suffix but does not contain any test cases defined using the different
-forms of the <code>it</code> and <code>test</code> functions from Jasmine, Jest, Mocha, or Node.js testing API.</p>
+<p>This rule flags any file that has <code>.test</code> or <code>.spec</code> as part of its suffix but does not contain any test cases defined using
+the different forms of the <code>it</code> and <code>test</code> functions from Jasmine, Jest, Mocha, or Node.js testing API.</p>
 <h2>How to fix it</h2>
-<p>To fix a test file that doesn’t contain any test cases, you should add test cases or delete the file if it isn’t needed.</p>
+<p>Add test cases to the file or delete it if it isn’t needed anymore.</p>
 <h3>Code examples</h3>
 <h4>Noncompliant code example</h4>
 <pre data-diff-id="1" data-diff-type="noncompliant">

sonar-plugin/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S3358.html

@@ -30,4 +30,9 @@ <h3>Exceptions</h3>
 &lt;/&gt;
 );
 </pre>
+<h2>Resources</h2>
+<h3>Articles &amp; blog posts</h3>
+<ul>
+  <li> Sonar - <a href="https://www.sonarsource.com/blog/stop-nesting-ternaries-javascript/">Stop nesting ternaries in JavaScript</a> </li>
+</ul>
 

sonar-plugin/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S5542.html

@@ -14,9 +14,9 @@ <h2>Why is this an issue?</h2>
 </ol>
 <p>For these reasons, as soon as cryptography is included in a project, it is important to choose encryption algorithms that are considered strong and
 secure by the cryptography community.</p>
-<p>For AES, the weakest modes are CBC (Cipher Block Chaining) and ECB</p>
-<p>(Electronic Codebook), as they are either vulnerable to padding oracles or do not provide authentication mechanisms.</p>
-<p>And for RSA, the weakest algorithms are either using it without padding or using the PKCS1v1.5 padding scheme.</p>
+<p>For AES, the weakest modes are CBC (Cipher Block Chaining) and ECB (Electronic Codebook) because they are either vulnerable to padding oracles or
+do not provide authentication mechanisms.</p>
+<p>For RSA, the weakest algorithms are either using it without padding or using the PKCS1v1.5 padding scheme.</p>
 <h3>What is the potential impact?</h3>
 <p>The cleartext of an encrypted message might be recoverable. Additionally, it might be possible to modify the cleartext of an encrypted message.</p>
 <p>Below are some real-world scenarios that illustrate possible impacts of an attacker exploiting the vulnerability.</p>

sonar-plugin/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S5547.html

@@ -3,9 +3,9 @@ <h2>Why is this an issue?</h2>
 <p>Encryption algorithms are essential for protecting sensitive information and ensuring secure communication in various domains. They are used for
 several important reasons:</p>
 <ul>
-  <li> Confidentiality, privacy, and intellectual property protection. </li>
-  <li> Security during transmission or on storage devices. </li>
-  <li> Data integrity, general trust, and authentication. </li>
+  <li> Confidentiality, privacy, and intellectual property protection </li>
+  <li> Security during transmission or on storage devices </li>
+  <li> Data integrity, general trust, and authentication </li>
 </ul>
 <p>When selecting encryption algorithms, tools, or combinations, you should also consider two things:</p>
 <ol>

sonar-plugin/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S5659.html

@@ -62,13 +62,13 @@ <h4>Verify the signature of your tokens</h4>
 signatures, they are not serving their purpose.</p>
 <p>Every time your application receives a JWT, it needs to decode the token to extract the information contained within. It is during this decoding
 process that the signature of the JWT should also be checked.</p>
-<p>To resolve the issue follow these instructions:</p>
+<p>To resolve the issue, follow these instructions:</p>
 <ol>
   <li> Use framework-specific functions for signature verification: Most programming frameworks that support JWTs provide specific functions to not
   only decode a token but also validate its signature simultaneously. Make sure to use these functions when handling incoming tokens. </li>
   <li> Handle invalid signatures appropriately: If a JWT’s signature does not validate correctly, it means the token is not trustworthy, indicating
-  potential tampering. The action to take on encountering an invalid token should be denying the request carrying it and logging the event for further
-  investigation. </li>
+  potential tampering. The action to take when encountering an invalid token should be denying the request carrying it and logging the event for
+  further investigation. </li>
   <li> Incorporate signature validation in your tests: When you are writing tests for your application, include tests that check the signature
   validation functionality. This can help you catch any instances where signature verification might be unintentionally skipped or bypassed. </li>
 </ol>

sonar-plugin/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S5743.html

@@ -1,3 +1,4 @@
+<p>This rule is deprecated, and will eventually be removed.</p>
 <p>By default, web browsers perform <a href="https://developer.mozilla.org/en-US/docs/Web/Performance/dns-prefetch/">DNS prefetching</a> to reduce
 latency due to DNS resolutions required when an user clicks links from a website page.</p>
 <p>For instance on example.com the hyperlink below contains a cross-origin domain name that must be resolved to an IP address by the web browser:</p>

sonar-plugin/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S5743.json

@@ -1,21 +1,18 @@
 {
-  "title": "Allowing browsers to perform DNS prefetching  is security-sensitive",
+  "title": "Allowing browsers to perform DNS prefetching is security-sensitive",
   "type": "SECURITY_HOTSPOT",
   "code": {
     "impacts": {
       "SECURITY": "LOW"
     },
     "attribute": "COMPLETE"
   },
-  "status": "ready",
+  "status": "deprecated",
   "remediation": {
     "func": "Constant\/Issue",
     "constantCost": "10min"
   },
-  "tags": [
-    "privacy",
-    "express.js"
-  ],
+  "tags": [],
   "defaultSeverity": "Minor",
   "ruleSpecification": "RSPEC-5743",
   "sqKey": "S5743",

sonar-plugin/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S6245.html

@@ -1,3 +1,4 @@
+<p>This rule is deprecated, and will eventually be removed.</p>
 <p>Server-side encryption (SSE) encrypts an object (not the metadata) as it is written to disk (where the S3 bucket resides) and decrypts it as it is
 read from disk. This doesn’t change the way the objects are accessed, as long as the user has the necessary permissions, objects are retrieved as if
 they were unencrypted. Thus, SSE only helps in the event of disk thefts, improper disposals of disks and other attacks on the AWS infrastructure

sonar-plugin/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S6245.json

@@ -7,11 +7,8 @@
     },
     "attribute": "COMPLETE"
   },
-  "status": "ready",
-  "tags": [
-    "aws",
-    "cwe"
-  ],
+  "status": "deprecated",
+  "tags": [],
   "defaultSeverity": "Minor",
   "ruleSpecification": "RSPEC-6245",
   "sqKey": "S6245",

sonar-plugin/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S6859.html

@@ -1,7 +1,8 @@
 <h2>Why is this an issue?</h2>
-<p>In Node.js importing modules is doable by providing an absolute path such as <code>/lib/foo/bar.js</code>. Doing this restricts the portability of
-your code, making it specific to your computer’s file system and potentially causing issues when the code is distributed, for example, through NPM
-packages.</p>
+<p>In Node.js, it’s possible to import modules by specifying an absolute path, such as <code>/lib/foo/bar.js</code>. However, this approach can limit
+the portability of your code, as it becomes tied to your computer’s file system. This could potentially lead to problems when the code is distributed,
+for instance, via NPM packages. Therefore, it’s advisable to use relative paths or module names for importing modules to enhance the portability and
+compatibility of your code across different systems.</p>
 <h2>How to fix it</h2>
 <p>Replace the absolute path with one that is relative to your current file.</p>
 <h3>Code examples</h3>

sonar-plugin/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S6861.html

@@ -36,6 +36,7 @@ <h2>Resources</h2>
 <h3>Documentation</h3>
 <ul>
   <li> MDN web docs - <a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/let">let</a> </li>
+  <li> MDN web docs - <a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/const">const</a> </li>
   <li> MDN web docs - <a href="https://developer.mozilla.org/en-US/docs/Glossary/Mutable">Mutable</a> </li>
   <li> MDN web docs - <a href="https://developer.mozilla.org/en-US/docs/Glossary/Immutable">Immutable</a> </li>
 </ul>

sonar-plugin/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/Sonar_way_profile.json

@@ -178,7 +178,6 @@
     "S5736",
     "S5739",
     "S5742",
-    "S5743",
     "S5757",
     "S5759",
     "S5842",
@@ -198,7 +197,6 @@
     "S6079",
     "S6080",
     "S6092",
-    "S6245",
     "S6249",
     "S6252",
     "S6265",

sonarpedia.json

@@ -3,7 +3,7 @@
   "languages": [
     "JS"
   ],
-  "latest-update": "2023-11-22T14:26:39.901476Z",
+  "latest-update": "2023-12-21T17:10:12.037032Z",
   "options": {
     "no-language-in-filenames": true,
     "preserve-filenames": true