diff --git a/css-sonarpedia/sonarpedia.json b/css-sonarpedia/sonarpedia.json index 0e415b7216f..60bb012a4f5 100644 --- a/css-sonarpedia/sonarpedia.json +++ b/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 } diff --git a/sonar-plugin/css/src/main/resources/org/sonar/l10n/css/rules/css/S4663.html b/sonar-plugin/css/src/main/resources/org/sonar/l10n/css/rules/css/S4663.html index 98b9759c7bc..0ae79ebbd38 100644 --- a/sonar-plugin/css/src/main/resources/org/sonar/l10n/css/rules/css/S4663.html +++ b/sonar-plugin/css/src/main/resources/org/sonar/l10n/css/rules/css/S4663.html @@ -1,5 +1,5 @@
Empty comments like the following don’t improve readability and might indicate an oversight.
+Empty comments, as shown in the example, hurt readability and might indicate an oversight.
/* */ @@ -7,5 +7,5 @@-Why is this an issue?
*/
A meaningful text should be added to the comment or the comment markers should be removed.
+Some meaningful text should be added to the comment, or the comment markers should be removed.
diff --git a/sonar-plugin/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S2187.html b/sonar-plugin/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S2187.html index 6cf98ba4399..ddc452a26eb 100644 --- a/sonar-plugin/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S2187.html +++ b/sonar-plugin/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S2187.html @@ -6,10 +6,10 @@This rule flags any file that has a .test
or .spec
suffix but does not contain any test cases defined using the different
-forms of the it
and test
functions from Jasmine, Jest, Mocha, or Node.js testing API.
This rule flags any file that has .test
or .spec
as part of its suffix but does not contain any test cases defined using
+the different forms of the it
and test
functions from Jasmine, Jest, Mocha, or Node.js testing API.
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.
+Add test cases to the file or delete it if it isn’t needed anymore.
diff --git a/sonar-plugin/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S3358.html b/sonar-plugin/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S3358.html index bab3b9a1536..defd7f7cdac 100644 --- a/sonar-plugin/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S3358.html +++ b/sonar-plugin/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S3358.html @@ -30,4 +30,9 @@+Exceptions
</> );
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.
-For AES, the weakest modes are CBC (Cipher Block Chaining) and ECB
-(Electronic Codebook), as they are either vulnerable to padding oracles or do not provide authentication mechanisms.
-And for RSA, the weakest algorithms are either using it without padding or using the PKCS1v1.5 padding scheme.
+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.
+For RSA, the weakest algorithms are either using it without padding or using the PKCS1v1.5 padding scheme.
The cleartext of an encrypted message might be recoverable. Additionally, it might be possible to modify the cleartext of an encrypted message.
Below are some real-world scenarios that illustrate possible impacts of an attacker exploiting the vulnerability.
diff --git a/sonar-plugin/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S5547.html b/sonar-plugin/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S5547.html index 098c1154d73..94225ace165 100644 --- a/sonar-plugin/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S5547.html +++ b/sonar-plugin/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S5547.html @@ -3,9 +3,9 @@Encryption algorithms are essential for protecting sensitive information and ensuring secure communication in various domains. They are used for several important reasons:
When selecting encryption algorithms, tools, or combinations, you should also consider two things:
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.
-To resolve the issue follow these instructions:
+To resolve the issue, follow these instructions:
This rule is deprecated, and will eventually be removed.
By default, web browsers perform DNS prefetching to reduce latency due to DNS resolutions required when an user clicks links from a website page.
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:
diff --git a/sonar-plugin/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S5743.json b/sonar-plugin/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S5743.json index c6039470578..c024f69d742 100644 --- a/sonar-plugin/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S5743.json +++ b/sonar-plugin/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S5743.json @@ -1,5 +1,5 @@ { - "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": { @@ -7,15 +7,12 @@ }, "attribute": "COMPLETE" }, - "status": "ready", + "status": "deprecated", "remediation": { "func": "Constant\/Issue", "constantCost": "10min" }, - "tags": [ - "privacy", - "express.js" - ], + "tags": [], "defaultSeverity": "Minor", "ruleSpecification": "RSPEC-5743", "sqKey": "S5743", diff --git a/sonar-plugin/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S6245.html b/sonar-plugin/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S6245.html index 32ddd21bec6..3eb3b8fe391 100644 --- a/sonar-plugin/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S6245.html +++ b/sonar-plugin/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S6245.html @@ -1,3 +1,4 @@ +This rule is deprecated, and will eventually be removed.
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 diff --git a/sonar-plugin/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S6245.json b/sonar-plugin/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S6245.json index d86a8ecf47b..be0358c96cf 100644 --- a/sonar-plugin/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S6245.json +++ b/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", diff --git a/sonar-plugin/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S6859.html b/sonar-plugin/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S6859.html index 0ee0b0b9a13..6edfc99c62e 100644 --- a/sonar-plugin/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S6859.html +++ b/sonar-plugin/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S6859.html @@ -1,7 +1,8 @@
In Node.js importing modules is doable by providing an absolute path such as /lib/foo/bar.js
. 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.
In Node.js, it’s possible to import modules by specifying an absolute path, such as /lib/foo/bar.js
. 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.
Replace the absolute path with one that is relative to your current file.