SONARJAVA-6178 Update rule metadata

sonar-java-plugin/src/main/resources/org/sonar/l10n/java/rules/java/S4684.html

@@ -1,8 +1,11 @@
-<p>With Spring, when a request mapping method is configured to accept bean objects as arguments, the framework will automatically bind HTTP parameters
-to those objects' properties. If the targeted beans are also persistent entities, the framework will also store those properties in the storage
-backend, usually the application’s database.</p>
+<p>Mass assignment occurs when a framework automatically binds user-controlled input to objects that are directly persisted to a database backend. If
+the application does not restrict which fields are writable, an attacker can inject additional properties into a request to overwrite sensitive
+data—such as authorization levels, ownership, or workflow states. This lack of filtering allows internal server-managed properties to be externally
+modified through a single, unfiltered write operation.</p>
 <h2>Why is this an issue?</h2>
-<p>By accepting persistent entities as method arguments, the application allows clients to manipulate the object’s properties directly.</p>
+<p>Because the application does not enforce which fields are writable, an attacker can craft a request containing any document property, including
+those that are meant to be managed exclusively by the server. Fields controlling authorization, ownership, workflow state, or internal identifiers all
+become externally settable through a single unfiltered write operation.</p>
 <h3>What is the potential impact?</h3>
 <p>Attackers could forge malicious HTTP requests that will alter unexpected properties of persistent objects. This can lead to unauthorized
 modifications of the entity’s state. This is known as a <strong>mass assignment</strong> attack.</p>

sonar-java-plugin/src/main/resources/org/sonar/l10n/java/rules/java/S4684.json

@@ -1,5 +1,5 @@
 {
-  "title": "Persistent entities should not be used as arguments of \"@RequestMapping\" methods",
+  "title": "Database Operations should not be vulnerable to mass assignment",
   "type": "VULNERABILITY",
   "code": {
     "impacts": {

sonar-java-plugin/src/main/resources/org/sonar/l10n/java/rules/java/S8446.html

@@ -41,6 +41,6 @@ <h4>Compliant solution</h4>
 <h2>Resources</h2>
 <h3>Documentation</h3>
 <ul>
-  <li> <a href="https://openjdk.org/jeps/512">JEP 512: Compact Source Files and Instance Main Methods</a> </li>
+  <li><a href="https://openjdk.org/jeps/512">JEP 512: Compact Source Files and Instance Main Methods</a></li>
 </ul>
 

sonar-java-plugin/src/main/resources/org/sonar/l10n/java/rules/java/S8446.json

@@ -1,5 +1,5 @@
 {
-  "title": "Only one \"main\" method should be present",
+  "title": "Only one \"main\" method should be defined in a class",
   "type": "CODE_SMELL",
   "status": "ready",
   "remediation": {

sonar-java-plugin/src/main/resources/org/sonar/l10n/java/rules/java/S8447.html

@@ -5,8 +5,8 @@ <h2>Why is this an issue?</h2>
 <p>Traditionally, the explicit constructor invocation (<code>super(…​)</code> or <code>this(…​)</code>) had to be the first statement in a
 constructor, forcing subclass field initialization to happen after the superclass was already constructed. If the superclass constructor calls an
 overridable method, the subclass implementation will see default values (such as <code>null</code>, <code>0</code>, or <code>false</code>) for its
-fields instead of the values intended by the caller. This leads to subtle bugs, `NullPointerException`s, or inconsistent object states that are
-difficult to debug.</p>
+fields instead of the values intended by the caller. This leads to subtle bugs, <code>NullPointerException</code>s, or inconsistent object states that
+are difficult to debug.</p>
 <h2>How to fix it</h2>
 <p>Move the initialization of subclass fields before the <code>super()</code> call. This takes advantage of flexible constructor bodies to ensure that
 the subclass state is established before the superclass constructor begins its execution. Alternatively, if the method in the superclass does not need
@@ -16,10 +16,10 @@ <h4>Noncompliant code example</h4>
 <pre data-diff-id="1" data-diff-type="noncompliant">
 class Super {
     Super() {
-        overriddenMethod();
+        foo();
     }
 
-    void overriddenMethod() {
+    void foo() {
         System.out.println("Base logic");
     }
 }
@@ -29,11 +29,11 @@ <h4>Noncompliant code example</h4>
 
     Sub(int x) {
         super();
-        this.x = x; // Noncompliant: x is uninitialized when overriddenMethod is called by Super()
+        this.x = x; // Noncompliant: x is uninitialized when foo is called by Super()
     }
 
     @Override
-    void overriddenMethod() {
+    void foo() {
         System.out.println(x); // Prints 0 instead of the value of x
     }
 }
@@ -42,10 +42,10 @@ <h4>Compliant solution</h4>
 <pre data-diff-id="1" data-diff-type="compliant">
 class Super {
     Super() {
-        overriddenMethod();
+        foo();
     }
 
-    void overriddenMethod() {
+    void foo() {
         System.out.println("Base logic");
     }
 }
@@ -59,21 +59,21 @@ <h4>Compliant solution</h4>
     }
 
     @Override
-    void overriddenMethod() {
+    void foo() {
         System.out.println(x); // Prints the expected value
     }
 }
 </pre>
 <p>Alternatively, if the method in the superclass does not need to be overridden, it can be marked as <code>final</code> or <code>private</code> to
 prevent the issue entirely.</p>
 <h4>Noncompliant code example</h4>
-<pre data-diff-id="1" data-diff-type="noncompliant">
+<pre data-diff-id="2" data-diff-type="noncompliant">
 class Super {
     Super() {
-        overriddenMethod();
+        foo();
     }
 
-    void overriddenMethod() {
+    void foo() {
         System.out.println("Base logic");
     }
 }
@@ -83,23 +83,23 @@ <h4>Noncompliant code example</h4>
 
     Sub(int x) {
         super();
-        this.x = x; // Noncompliant: x is uninitialized when overriddenMethod is called by Super()
+        this.x = x; // Noncompliant: x is uninitialized when foo is called by Super()
     }
 
     @Override
-    void overriddenMethod() {
+    void foo() {
         System.out.println(x); // Prints 0 instead of the value of x
     }
 }
 </pre>
 <h4>Compliant solution</h4>
-<pre data-diff-id="1" data-diff-type="compliant">
+<pre data-diff-id="2" data-diff-type="compliant">
 class Super {
     Super() {
-        overriddenMethod();
+        foo();
     }
 
-    final void finalMethod() {
+    final void foo() {
         System.out.println("Base logic");
     }
 }
@@ -109,13 +109,13 @@ <h4>Compliant solution</h4>
 
     Sub(int x) {
         super();
-        this.x = x; // Compliant: finalMethod is final, so it cannot be overridden and will not access uninitialized fields
+        this.x = x; // Compliant: foo is final, so it cannot be overridden and will not access uninitialized fields
     }
 }
 </pre>
 <h2>Resources</h2>
 <h3>Documentation</h3>
 <ul>
-  <li> <a href="https://openjdk.org/jeps/513">JEP 513: Flexible Constructor Bodies</a> </li>
+  <li><a href="https://openjdk.org/jeps/513">JEP 513: Flexible Constructor Bodies</a></li>
 </ul>
 

sonarpedia.json

@@ -3,9 +3,9 @@
   "languages": [
     "JAVA"
   ],
-  "latest-update": "2026-02-26T08:20:43.956169Z",
+  "latest-update": "2026-02-27T13:15:37.935044048Z",
   "options": {
     "no-language-in-filenames": true,
     "preserve-filenames": false
   }
-}
+}