[Education] Modify rule S5131: Improve language (#1177)

rules/S5131/common/fix/data_encoding.adoc

@@ -1,9 +1,9 @@
 ==== Encode data according to the HTML context
 
-The best approach to protect against XSS is to systematically encode data that are written to HTML documents.
-The goal is to leave the data intact from the end user's point of view but makes it uninterpretable by web browsers.
+The best approach to protect against XSS is to systematically encode data that is written to HTML documents.
+The goal is to leave the data intact from the end user's point of view but make it uninterpretable by web browsers.
 
-XSS exploitation techniques vary depending on the HTML context where malicious inputs are injected. For each HTML context, there is a specific encoding to prevent JavaScript code from being interpreted.
+XSS exploitation techniques vary depending on the HTML context where malicious input is injected. For each HTML context, there is a specific encoding to prevent JavaScript code from being interpreted.
 The following table summarizes the encoding to apply for each HTML context.
 
 [options="header",cols="a,a,a,a"]
@@ -85,7 +85,7 @@ HTML entity encoding: replace the following characters with HTML-safe sequences.
   ...
 </div>
 ----
-| *Dangerous context*: no output encoding will prevent XSS fully.
+| *Dangerous context*: HTML output encoding will not prevent XSS fully.
 
 
 | In a URL attribute
@@ -124,7 +124,7 @@ HTML entity encoding: replace the following characters with HTML-safe sequences.
   alert(1)
 </script>
 ----
-| *Dangerous context*: no output encoding will prevent XSS fully.
+| *Dangerous context*: HTML output encoding will not prevent XSS fully.
 To pass values to a JavaScript context, the recommended way is to use a data attribute:
 
 [source,html]

rules/S5131/common/pitfalls/validation.adoc

@@ -2,7 +2,7 @@
 
 Validation of user inputs is a good practice to protect against various injection attacks. But for XSS, validation on its own is not the recommended approach.
 
-As an example, filtering out user inputs based on a deny-list will never fully prevent XSS vulnerability from being exploited. This practice is sometimes used by web application firewalls. It's only a matter of time for malicious users to find the exploitation payload that will defeat the filters.
+As an example, filtering out user inputs based on a deny-list will never fully prevent XSS vulnerability from being exploited. This practice is sometimes used by web application firewalls. It is only a matter of time for malicious users to find the exploitation payload that will defeat the filters.
 
 Another example is applications that allow users or third-party services to send HTML content to be used by the application. A common approach is trying to parse HTML and strip sensitive HTML tags. Again, this deny-list approach is vulnerable by design: maintaining a list of sensitive HTML tags, in the long run, is very difficult.
 

rules/S5131/impact.adoc

@@ -2,7 +2,7 @@
 
 A well-intentioned user opens a malicious link that injects data into the web
 application. This data can be text, but it can also be arbitrary code that can
-be interpreted by the target user's browser, such as HTML, CSS, or Javascript.
+be interpreted by the target user's browser, such as HTML, CSS, or JavaScript.
 
 Below are some real-world scenarios that illustrate the various effects of an
 attacker exploiting the vulnerability.

rules/S5131/java/how-to-fix-it/thymeleaf.adoc

@@ -30,7 +30,7 @@ h| Compliant solution
 
 include::../../common/fix/data_encoding.adoc[]
 
-For HTML encoding, Javascript encoding, and CSS encoding, the documentation
+For HTML encoding, JavaScript encoding, and CSS encoding, the documentation
 allows the use of `unescaped text`, in only two different ways:
 
 * with the attribute `th:utext`.

rules/S5131/rationale.adoc

@@ -1,7 +1,7 @@
-Reflected cross-site scripting (XSS) occurs in a web application when the application retrieves data (e.g., parameters or headers) from an incoming HTTP request and inserts it into its HTTP response without first sanitizing it. The most common cause is the insertion of GET parameters.
+Reflected cross-site scripting (XSS) occurs in a web application when the application retrieves data like parameters or headers from an incoming HTTP request and inserts it into its HTTP response without first sanitizing it. The most common cause is the insertion of GET parameters.
 
 // image:common/images/browser.png[]
-When a well-intentioned user opens a link to a page that is vulnerable to reflected XSS, they are exposed to attacks that target their own browser.
+When well-intentioned users open a link to a page that is vulnerable to reflected XSS, they are exposed to attacks that target their own browser.
 
 A user with malicious intent carefully crafts the link beforehand.
 // Here is an example:

rules/S5131/threats.adoc

@@ -5,16 +5,19 @@ the user who is the victim. This may result in loss of integrity and theft of
 the benevolent user's data.
 
 ==== Identity spoofing
+
 The forged link injects malicious code into the web application.
 The code enables identity spoofing thanks to cookie theft.
 
 ==== Record user activity
+
 The forged link injects malicious code into the web application. To leak
 confidential information, attackers can inject code that records keyboard
 activity (keylogger) and even requests access to other devices, such as the
 camera or microphone.
 
-==== Chaining XSS with other vulnerabilities 
+==== Chaining XSS with other vulnerabilities
+
 In many cases, bug hunters and attackers chain cross-site scripting
 vulnerabilities with other vulnerabilities to maximize their impact. +
 For example, an XSS can be used as the first step to exploit more dangerous