SONARXML-173 Update rule metadata (#264)

sonar-xml-plugin/src/main/resources/org/sonar/l10n/xml/rules/xml/S103.html

@@ -1,2 +1,3 @@
+<h2>Why is this an issue?</h2>
 <p>Having to scroll horizontally makes it harder to get a quick overview and understanding of any piece of code.</p>
 

sonar-xml-plugin/src/main/resources/org/sonar/l10n/xml/rules/xml/S105.html

@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>Developers should not need to configure the tab width of their text editors in order to be able to read source code.</p>
 <p>So the use of the tabulation character must be banned.</p>
 

sonar-xml-plugin/src/main/resources/org/sonar/l10n/xml/rules/xml/S1120.html

@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>Proper indentation is a simple and effective way to improve the code’s readability. Consistent indentation among the developers within a team also
 reduces the differences that are committed to source control systems, making code reviews easier.</p>
 <p>By default this rule checks that each block of code is indented, although it does not check the size of the indent. Parameter "indentSize" allows

sonar-xml-plugin/src/main/resources/org/sonar/l10n/xml/rules/xml/S1134.html

@@ -1,7 +1,8 @@
+<h2>Why is this an issue?</h2>
 <p><code>FIXME</code> tags are commonly used to mark places where a bug is suspected, but which the developer wants to deal with later.</p>
 <p>Sometimes the developer will not have the time or will simply forget to get back to that tag.</p>
 <p>This rule is meant to track those tags and to ensure that they do not go unnoticed.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 &lt;!-- FIXME we should update version to 3.8.1 --&gt;
 &lt;dependency&gt;
@@ -10,7 +11,7 @@ <h2>Noncompliant Code Example</h2>
   &lt;version&gt;3.6&lt;/version&gt;
 &lt;/dependency&gt;
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://cwe.mitre.org/data/definitions/546">MITRE, CWE-546</a> - Suspicious Comment </li>
 </ul>

sonar-xml-plugin/src/main/resources/org/sonar/l10n/xml/rules/xml/S1135.html

@@ -1,7 +1,8 @@
+<h2>Why is this an issue?</h2>
 <p><code>TODO</code> tags are commonly used to mark places where some more code is required, but which the developer wants to implement later.</p>
 <p>Sometimes the developer will not have the time or will simply forget to get back to that tag.</p>
 <p>This rule is meant to track those tags and to ensure that they do not go unnoticed.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 &lt;!-- TODO Drop this dependency --&gt;
 &lt;dependency&gt;
@@ -10,7 +11,7 @@ <h2>Noncompliant Code Example</h2>
   &lt;version&gt;3.8.1&lt;/version&gt;
 &lt;/dependency&gt;
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://cwe.mitre.org/data/definitions/546">MITRE, CWE-546</a> - Suspicious Comment </li>
 </ul>

sonar-xml-plugin/src/main/resources/org/sonar/l10n/xml/rules/xml/S125.html

@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>Programmers should not comment out code as it bloats programs and reduces readability.</p>
 <p>Unused code should be deleted and can be retrieved from source control history if required.</p>
 

sonar-xml-plugin/src/main/resources/org/sonar/l10n/xml/rules/xml/S1778.html

@@ -1,18 +1,19 @@
+<h2>Why is this an issue?</h2>
 <p>The prolog header is the following piece of code that some XML documents start with:</p>
 <pre>
 &lt;?xml version="y.x" encoding="zzzzz"?&gt;
 </pre>
 <p>When the prolog exists in an XML document, it should be at the beginning of the file to enable programs to determine the encoding of non-UTF-8,
 non-UTF-16 files.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 &lt;!-- Generated file --&gt;  &lt;!--  Noncompliant  --&gt;
 &lt;?xml version="1.0" encoding="UTF-8"?&gt;
 &lt;firstNode&gt;
   content
 &lt;/firstNode&gt;
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 &lt;?xml version="1.0" encoding="UTF-8"?&gt;
 &lt;!-- Generated file --&gt;

sonar-xml-plugin/src/main/resources/org/sonar/l10n/xml/rules/xml/S2068.json

@@ -7,9 +7,7 @@
     "constantCost": "30min"
   },
   "tags": [
-    "cwe",
-    "sans-top25-porous",
-    "owasp-a2"
+    "cwe"
   ],
   "defaultSeverity": "Blocker",
   "ruleSpecification": "RSPEC-2068",

sonar-xml-plugin/src/main/resources/org/sonar/l10n/xml/rules/xml/S2260.html

@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>When the XML parser fails, it is possible to record the failure as a violation on the file. This way, not only it is possible to track the number
 of files that do not parse but also to easily find out why they do not parse.</p>
 

sonar-xml-plugin/src/main/resources/org/sonar/l10n/xml/rules/xml/S2321.html

@@ -1,9 +1,10 @@
+<h2>Why is this an issue?</h2>
 <p>Each element should be on a line to itself.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 &lt;parent&gt;&lt;child /&gt;&lt;/parent&gt;  &lt;!-- Noncompliant --&gt;
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 &lt;parent&gt;
   &lt;child /&gt;

sonar-xml-plugin/src/main/resources/org/sonar/l10n/xml/rules/xml/S2647.html

@@ -1,6 +1,7 @@
+<h2>Why is this an issue?</h2>
 <p>Basic authentication’s only means of obfuscation is Base64 encoding. Since Base64 encoding is easily recognized and reversed, it offers only the
 thinnest veil of protection to your users, and should not be used.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 // in web.xml
 &lt;web-app  ...&gt;
@@ -10,7 +11,7 @@ <h2>Noncompliant Code Example</h2>
   &lt;/login-config&gt;
 &lt;/web-app&gt;
 </pre>
-<h2>Exceptions</h2>
+<h3>Exceptions</h3>
 <p>The rule will not raise any issue if HTTPS is enabled, on any URL-pattern.</p>
 <pre>
 &lt;web-app  ...&gt;
@@ -26,7 +27,7 @@ <h2>Exceptions</h2>
   &lt;/security-constraint&gt;
 &lt;/web-app&gt;
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://owasp.org/Top10/A04_2021-Insecure_Design/">OWASP Top 10 2021 Category A4</a> - Insecure Design </li>
   <li> <a href="https://www.owasp.org/www-project-top-ten/2017/A3_2017-Sensitive_Data_Exposure">OWASP Top 10 2017 Category A3</a> - Sensitive Data

sonar-xml-plugin/src/main/resources/org/sonar/l10n/xml/rules/xml/S2647.json

@@ -7,9 +7,7 @@
     "constantCost": "2h"
   },
   "tags": [
-    "cwe",
-    "sans-top25-porous",
-    "owasp-a3"
+    "cwe"
   ],
   "defaultSeverity": "Critical",
   "ruleSpecification": "RSPEC-2647",

sonar-xml-plugin/src/main/resources/org/sonar/l10n/xml/rules/xml/S3281.html

@@ -1,8 +1,9 @@
+<h2>Why is this an issue?</h2>
 <p>Default interceptors, such as application security interceptors, must be listed in the <code>ejb-jar.xml</code> file, or they will not be treated
 as default.</p>
 <p>This rule applies to projects that contain JEE Beans (any one of <code>javax.ejb.Singleton</code>, <code>MessageDriven</code>,
 <code>Stateless</code> or <code>Stateful</code>).</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 // file: ejb-interceptors.xml
 &lt;assembly-descriptor&gt;
@@ -12,7 +13,7 @@ <h2>Noncompliant Code Example</h2>
    &lt;/interceptor-binding&gt;
 &lt;/assembly-descriptor&gt;
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 // file: ejb-jar.xml
 &lt;assembly-descriptor&gt;
@@ -22,7 +23,7 @@ <h2>Compliant Solution</h2>
    &lt;/interceptor-binding&gt;
 &lt;/assembly-descriptor&gt;
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://owasp.org/Top10/A05_2021-Security_Misconfiguration/">OWASP Top 10 2021 Category A5</a> - Security Misconfiguration </li>
   <li> <a href="https://owasp.org/www-project-top-ten/2017/A6_2017-Security_Misconfiguration">OWASP Top 10 2017 Category A6</a> - Security

sonar-xml-plugin/src/main/resources/org/sonar/l10n/xml/rules/xml/S3281.json

@@ -6,9 +6,7 @@
     "func": "Constant\/Issue",
     "constantCost": "5min"
   },
-  "tags": [
-    "owasp-a6"
-  ],
+  "tags": [],
   "defaultSeverity": "Blocker",
   "ruleSpecification": "RSPEC-3281",
   "sqKey": "S3281",

sonar-xml-plugin/src/main/resources/org/sonar/l10n/xml/rules/xml/S3282.html

@@ -1,6 +1,7 @@
+<h2>Why is this an issue?</h2>
 <p>Exclusions for default interceptors can be declared either in xml or as class annotations. Since annotations are more visible to maintainers, they
 are preferred.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 &lt;assembly-descriptor&gt;
       &lt;interceptor-binding&gt;
@@ -14,7 +15,7 @@ <h2>Noncompliant Code Example</h2>
 
 &lt;/assembly-descriptor&gt;
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 @ExcludeDefaultInterceptors
 public class MyExcludedClass implements MessageListener

sonar-xml-plugin/src/main/resources/org/sonar/l10n/xml/rules/xml/S3330.json

@@ -8,9 +8,7 @@
   },
   "tags": [
     "cwe",
-    "sans-top25-insecure",
-    "privacy",
-    "owasp-a7"
+    "privacy"
   ],
   "defaultSeverity": "Minor",
   "ruleSpecification": "RSPEC-3330",

sonar-xml-plugin/src/main/resources/org/sonar/l10n/xml/rules/xml/S3355.html

@@ -1,13 +1,14 @@
+<h2>Why is this an issue?</h2>
 <p>Every filter defined in <code>web.xml</code> file should be used in a <code>&lt;filter-mapping&gt;</code> element. Otherwise such filters are not
 invoked.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
   &lt;filter&gt;
      &lt;filter-name&gt;DefinedNotUsed&lt;/filter-name&gt;
      &lt;filter-class&gt;com.myco.servlet.ValidationFilter&lt;/filter-class&gt;
   &lt;/filter&gt;
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
   &lt;filter&gt;
      &lt;filter-name&gt;ValidationFilter&lt;/filter-name&gt;
@@ -19,7 +20,7 @@ <h2>Compliant Solution</h2>
      &lt;url-pattern&gt;/*&lt;/url-pattern&gt;
   &lt;/filter-mapping&gt;
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://owasp.org/Top10/A05_2021-Security_Misconfiguration/">OWASP Top 10 2021 Category A5</a> - Security Misconfiguration </li>
   <li> <a href="https://owasp.org/www-project-top-ten/2017/A6_2017-Security_Misconfiguration">OWASP Top 10 2017 Category A6</a> - Security

sonar-xml-plugin/src/main/resources/org/sonar/l10n/xml/rules/xml/S3355.json

@@ -6,9 +6,7 @@
     "func": "Constant\/Issue",
     "constantCost": "30min"
   },
-  "tags": [
-    "owasp-a6"
-  ],
+  "tags": [],
   "defaultSeverity": "Critical",
   "ruleSpecification": "RSPEC-3355",
   "sqKey": "S3355",

sonar-xml-plugin/src/main/resources/org/sonar/l10n/xml/rules/xml/S3373.html

@@ -1,9 +1,10 @@
+<h2>Why is this an issue?</h2>
 <p>It makes sense to handle all related actions in the same place. Thus, the same <code>&lt;action&gt;</code> might logically handle all facets of
 CRUD on an entity, with no confusion in the naming about which <code>&lt;forward/&gt;</code> handles which facet. But go very far beyond that, and it
 becomes difficult to maintain a transparent naming convention.</p>
 <p>So to ease maintenance, this rule raises an issue when an <code>&lt;action&gt;</code> has more than the allowed number of
 <code>&lt;forward/&gt;</code> tags.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <p>With the default threshold of 4:</p>
 <pre>
 &lt;action path='/book' type='myapp.BookDispatchAction' name='form' parameter='method'&gt;
@@ -14,7 +15,7 @@ <h2>Noncompliant Code Example</h2>
   &lt;forward name='authorRead' path='WEB-INF/jsp/AuthorDetails' redirect='false'/&gt;  &lt;!-- Noncompliant --&gt;
 &lt;/action&gt;
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 &lt;action path='/book' type='myapp.BookDispatchAction' name='bookForm' parameter='method'&gt;
   &lt;forward name='create' path='/WEB-INF/jsp/BookCreate.jspx' redirect='false'/&gt;

sonar-xml-plugin/src/main/resources/org/sonar/l10n/xml/rules/xml/S3374.html

@@ -1,10 +1,11 @@
+<h2>Why is this an issue?</h2>
 <p>According to the Common Weakness Enumeration,</p>
 <blockquote>
   <p>If two validation forms have the same name, the Struts Validator arbitrarily chooses one of the forms to use for input validation and discards
   the other. This decision might not correspond to the programmer’s expectations…​</p>
 </blockquote>
 <p>In such a case, it is likely that the two forms should be combined. At the very least, one should be removed.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 &lt;form-validation&gt;
   &lt;formset&gt;
@@ -13,15 +14,15 @@ <h2>Noncompliant Code Example</h2>
   &lt;/formset&gt;
 &lt;/form-validation&gt;
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 &lt;form-validation&gt;
   &lt;formset&gt;
     &lt;form name="BookForm"&gt; ... &lt;/form&gt;
   &lt;/formset&gt;
 &lt;/form-validation&gt;
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://cwe.mitre.org/data/definitions/102">MITRE, CWE-102</a> - Struts: Duplicate Validation Forms </li>
   <li> <a href="https://owasp.org/www-community/vulnerabilities/Improper_Data_Validation">OWASP, Improper Data Validation</a> - Struts: Duplicate

sonar-xml-plugin/src/main/resources/org/sonar/l10n/xml/rules/xml/S3417.html

@@ -1,6 +1,7 @@
+<h2>Why is this an issue?</h2>
 <p>Whether they are disallowed locally for security, license, or dependability reasons, forbidden dependencies should not be used.</p>
 <p>This rule raises an issue when the group or artifact id of a direct dependency matches the configured forbidden dependency pattern.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <p>With a parameter of: <code>*:.*log4j.*</code></p>
 <pre>
 &lt;dependency&gt; &lt;!-- Noncompliant --&gt;

sonar-xml-plugin/src/main/resources/org/sonar/l10n/xml/rules/xml/S3419.html

@@ -1,6 +1,7 @@
+<h2>Why is this an issue?</h2>
 <p>Shared naming conventions allow teams to collaborate effectively. This rule raises an issue when the a pom’s <code>groupId</code> does not match
 the provided regular expression.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <p>With the default regular expression: <code>(com|org)(\.[a-z][a-z-0-9]*)+</code></p>
 <pre>
 &lt;project ...&gt;
@@ -9,7 +10,7 @@ <h2>Noncompliant Code Example</h2>
   &lt;!-- ... --&gt;
 &lt;/project&gt;
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 &lt;project ...&gt;
   &lt;groupId&gt;com.myco&lt;/groupId&gt;

sonar-xml-plugin/src/main/resources/org/sonar/l10n/xml/rules/xml/S3420.html

@@ -1,6 +1,7 @@
+<h2>Why is this an issue?</h2>
 <p>Shared naming conventions allow teams to collaborate effectively. This rule raises an issue when a pom’s <code>artifactId</code> does not match the
 provided regular expression.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <p>With the default regular expression: <code>[a-z][a-z-0-9]+</code></p>
 <pre>
 &lt;project ...&gt;
@@ -9,7 +10,7 @@ <h2>Noncompliant Code Example</h2>
   &lt;!-- ... --&gt;
 &lt;/project&gt;
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
 &lt;project ...&gt;
   &lt;artifactId&gt;my-project&lt;/artifactId&gt;

sonar-xml-plugin/src/main/resources/org/sonar/l10n/xml/rules/xml/S3421.html

@@ -1,13 +1,14 @@
+<h2>Why is this an issue?</h2>
 <p>Deprecated features are those that have been retained temporarily for backward compatibility, but which will eventually be removed. In effect,
 deprecation announces a grace period to allow the smooth transition from the old features to the new ones. In that period, no use of the deprecated
 features should be added, and all existing uses should be gradually removed.</p>
 <p>This rule raises an issue when <code>${pom.*}</code> properties are used in a pom.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
   &lt;build&gt;
     &lt;finalName&gt;${pom.artifactId}-${pom.version}&lt;/finalName&gt;  &lt;!-- Noncompliant --&gt;
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
   &lt;build&gt;
     &lt;finalName&gt;${project.artifactId}-${project.version}&lt;/finalName&gt;

sonar-xml-plugin/src/main/resources/org/sonar/l10n/xml/rules/xml/S3422.html

@@ -1,6 +1,7 @@
+<h2>Why is this an issue?</h2>
 <p><code>system</code> dependencies are sought at a specific, specified path. This drastically reduces portability because if you deploy your artifact
 in an environment that’s not configured just like yours is, your code won’t work.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 &lt;dependency&gt;
   &lt;groupId&gt;javax.sql&lt;/groupId&gt;

sonar-xml-plugin/src/main/resources/org/sonar/l10n/xml/rules/xml/S3423.html

@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>The POM Code Convention is the Maven project’s internal recommendation for POM element ordering. It calls for listing modifiers in the following
 order:</p>
 <ol>
@@ -33,7 +34,7 @@
 </ol>
 <p>Not following this convention has no technical impact, but will reduce the pom’s readability because most developers are used to the standard
 order.</p>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://maven.apache.org/developers/conventions/code.html#POM_Code_Convention">POM Code Convention</a> </li>
 </ul>