55 lines
1.3 KiB
Plaintext
55 lines
1.3 KiB
Plaintext
=== How to fix it in Thymeleaf
|
|
|
|
The following code is vulnerable to cross-site scripting.
|
|
|
|
User input embedded in HTML code should be HTML-encoded to prevent the injection of additional code.
|
|
|
|
==== Non-compliant code example
|
|
|
|
[source,html,diff-id=1,diff-type=noncompliant]
|
|
----
|
|
<body>
|
|
<p th:utext="Hello, ${input}!" /> <!-- Noncompliant -->
|
|
<p>Hello, [(${input})]!</p> <!-- Noncompliant -->
|
|
</body>
|
|
----
|
|
|
|
==== Compliant solution
|
|
|
|
[source,html,diff-id=1,diff-type=compliant]
|
|
----
|
|
<body>
|
|
<p th:text="Hello, ${input}!" />
|
|
<p>Hello, [[${input}]]!</p>
|
|
</body>
|
|
----
|
|
|
|
=== How does this work?
|
|
|
|
include::../../common/fix/data_encoding.adoc[]
|
|
|
|
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`.
|
|
* with the inline expression `[(...)]`.
|
|
|
|
If you insert third party data into the pages, the regular attributes are
|
|
preferable:
|
|
|
|
* with the attribute `th:text`.
|
|
* The inline expression `[[...]]`.
|
|
|
|
They ensure that the correct encoding is used, regardless of the context in
|
|
which the user-controlled data is inserted. Thus, it is not necessary to specify a
|
|
particular encoder.
|
|
|
|
=== Pitfalls
|
|
|
|
include::../../common/pitfalls/validation.adoc[]
|
|
|
|
=== Going the extra mile
|
|
|
|
include::../../common/extra-mile/csp.adoc[]
|
|
|